Month: January 2011

Automatic Date Links in MediaWiki

I had time between 1:1s today to solve a wiki problem that’s been nagging me. My codes, let me show you them.

Problem: We have meetings.

What’s worse, we persist in having them every week. Being the kind of project we are, we keep agendas and notes from those meetings publicly and invite the community to participate (does your browser? Great!)

What you want, then, is for each week’s meeting notes to link to next week’s and last week’s, like such:

And so, we do. But those links have to be hand-edited every week. Indeed, the pages for various meeting notes have earnest, heart-wrenching pleas in HTML comments, like

<!– REPLACE YYYY-MM-DD with the previous and next week’s year-month-date –>

No one should have to live like that.

Solution: ParserFunctions

Our mediawiki install includes the ParserFunctions extension, which has a whole bag of tricks. One of these tricks is {{#time}}. #time lets you produce various kinds of time/date strings, to wit:

{{#time: Y-m-d }}

Particularly nice, though, is that you can specify relative times, e.g.

{{#time: Y-m-d|+1 week}}

The relative syntax is so flexible, in fact, that I can utter this monstrosity:

[[Platform/{{#time: Y-m-d|tuesday last week}}|« previous week]]

to link to last week’s notes from a given page!

Still with me? Because there’s one snag left. The above works for people who have a static front page with this week’s info, and only ever want to link one week back. But those relative dates are relative to now — what if I want each link in the chain to link to the week prior?

No problem — our pages are named according to their dates, so just make the link relative to that, instead:

[[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous week]]

Presto.

The things you learn while waiting for a phone call. If you want to get really exciting, you can do all this in transclusion tags, to have last week’s notes automatically added to this week, but that’s left as a terrifyingly-recursive exercise for the reader.

What’s your favourite mediawiki hack?

(PS – Full credit to Melissa for giving me the idea in the first place. I am naught but the implementor.)

It’s Almost Ready

Shipping great software to lots of people is hard. At Mozilla we talk about shipping only “when it’s ready,” and the devotion our community has to Firefox users, and to shipping them a high quality product, is unlike anything I’ve seen elsewhere. We answer to no one but you.

“When it’s ready” doesn’t mean we can take our time, though. Firefox 4 is good for the web, good for our users, and puts the heat on other vendors to up their own game. We need to ship it ASAP – we want release candidates in weeks, not months. And that means a hard look at our blocker list.

Blocker bugs have a rank order. If you can’t have all of them, there are some you’d want more than others, even though every single one of them is a bug we want to fix. That’s healthy. Building software means making those calls. Each bug is evaluated against whether it’s worth holding back the thousands of fixes that have already made it into the Firefox 4 tree. At this point, very few bugs are worth holding back that much awesome.

Hard vs. Soft Blocking1

To that end, then, if you watch bugzilla, you’ve seen blocker bugs sprouting one of two new whiteboard labels:

  • [hardblocker] – These bugs prevent us from shipping. We’ll hold the release for the very last one of them. A hard blocker is a failure of a core part of our release criteria, e.g. a crash, a memory leak, a performance hit, a security issue, a UI breakage that can’t be recovered from, an incompatibility we can’t stomach.
  • [softblocker] – These bugs are things we want to fix as soon as possible, but can ship with if the hard blockers are done. They can be fixed in maintenance releases if needed, or in Firefox 5 which, remember, is not so very far away. Soft blockers might include visual polish, strange edge cases, optional aspects of new specs, or opportunistic performance wins.

Hard blockers trump everything. That doesn’t mean they are the only things that will get fixed – indeed we hope and expect many of our soft blockers to make it in as well. We didn’t clear their blocking flags, they are still legit work items and have landing pre-approval. Soft blockers are what beltzner calls the “opportunity space” – the work that lifts the quality and delight of the product. But we have to make the hard calls, and soft blockers are second priority to shipping. People paid to work on Firefox will be focusing exclusively on hard blockers, first.

The hard blocker list is currently at 143. When it hits 0, we can ship. Let’s kill it dead.

[1] Inevitably, when we do a pass like this, someone will want to digress into a thread about nomenclature. “Why are they blockers if they don’t block?” “Are there hard soft blockers, or soft hard blockers?” I love the creativity of our community, but I think it’s a distraction right now, and I’d suggest to you that we have more interesting problems to solve in the next little while!