Mailing list talk has consequences

One of my engineers was leaving the building for a late lunch and held the door open for me and another director. Before we parted, we had a short chat in the doorway about approvals on a purchase order.

“Hey, I need to see your ID!” Building security yelled at us.

“Huh? What?” H— replied?

“That’s the new policy. I need to ask to see everyone’s keycard.”

“It must be related to that mailing list thread.” I told H—, matter-of-factly. (For over a week now, an internal mailing list thread has been going on about building security. I stopped reading when someone suggested that the only way to solve this was to install lasers to detect when two people enter with one card, and another one argued that we should just make an HR policy to fire anyone who lets anyone in without proper ID. The reason I stopped was because neither post was trolling us in jest.)

The building security guy continued indignantly, “Even if I know you, even if you’re a manager—and I know you two are managers. L—, the head of the company, said I must to ask for your ID or call her down to greet you in the lobby.” (Sidenote: L— is not the head of the company. On the other hand, poor L— suggested on the mailing list that any solution hopeless because building security is seriously underpaid by the owners, perhaps to the point of illegality.)

I joked, “Even if I thought the discussion that touched off this policy was a waste of everyone’s time?”

Building security apparently has about as much humor as our company mailing list. So I reluctantly dug through my wallet and and pulled out a blank white piece of plastic, that may or may not have been my car parking card—they’re identical and I do not have an RFID reader on my person.

He let me through anyway.

That’s good, because to this day I do not know the average airspeed of an unladen swallow.

response to questions concerning the VisualEditor

I feel somewhat responsible for putting James Forrester on the hot seat concerning [this article][Visual Editor post] as I was the one who asked him to take out time from his busy schedule to explain some of the challenges faced by the team concerning the project and manage expectations somewhat concerning the release.

I hope it is clear from the post that the [VisualEditor project][] has to overcome many “firsts” to become a reality. Some of the ones mentioned include:

1. The criteria to support 290 languages is beyond the scope of support of existing software.
2. The VisualEditor UI needs to be programmable in such a manner that “free form” HTML editing cannot be permitted unless those edits can be synced with an internal, client-side “data model.”
3. The VisualEditor needs to leave room for extensibility in all fronts to adapt to the extensible nature of current WikiText capabilities like transclusions and templates.
4. A **two-way** representation needs to be created out of wikitext to HTML *back to wikitext*. This cannot be emphasized enough since before the [parsoid project][], it was actually unclear if this was even possible.
5. In both the parser and in all points of the VisualEditor, edits must be made in a manner that only manipulates the areas intended by the editor so was to not introduce “dirty diffs”.
6. All of this must be done in a forward thinking transactional manner to allow things like real-time collaboration, micro-edits, and the ability to walk through actions.

[Visual Editor post]: http://blog.wikimedia.org/2012/12/07/inventing-as-we-go-building-a-visual-editor-for-mediawiki/ “Inventing as we go: building a visual editor for MediaWiki—Wikimedia”
[VisualEditor project]: http://www.mediawiki.org/wiki/VisualEditor “VisualEditor—MediaWiki”
[parsoid project]: http://www.mediawiki.org/wiki/Parsoid “Parsoid—MediaWiki”Continue reading