Deliberacy

a team in a rowboat on blue water
The Firefox community is kicking ass. We just worked through our first Aurora merge as part of our new rapid release process and in less than 6 weeks, the next train leaves the station. We are rewriting the way we build software and we are doing it fast.

We’re succeeding because we’re acting deliberately. We’re doing it on purpose. We know what we need our release process to do and we’re building forward from that, instead of shooting first and calling whatever we hit the target.

I’m glad that we’re being deliberate about how we build Firefox. We need to be deliberate about what we build, too. I’ll tell you how I think that should go, after a brief digression on how it has gone up until now.

(If you have no time for that, deb’s written a more concise introduction.)

Prehistory: Bugs

Historically, if you wanted to get a feature built, you filed a bug. Maybe you started a newsgroup thread, or an irc conversation but it wasn’t real until there was a bug. This is a great instinct. It makes the work concrete, it lets people opt in to tracking its progress, and it makes Bugzilla into a single source of truth about active work in the project.

Recent History: Prioritization

Bugs are good for tracking atomic pieces of work, but they are not good for overall project direction. As Mozilla grows, with more going on at once, we hit contention for scarce resources like code review, UX support, even permission to land at all, late in cycle.

Contention can be virtuous. It forces us to focus, but that focus is nearsighted. Managers ask their teams to work on high priority items, but priorities are often ad hoc (or post hoc!) Our releases have been driven by extremely smart people and they’ve been phenomenally successful, but the lack of a centralized, up-front plan and prioritization has lead to wasted effort and missed opportunities. It also bleeds those smart people dry, and we can do better.

The Future, In 4 Parts

We’re still going to use bugs to track work. We’re still going to need ideas from everywhere and we’re still going to need brilliant people, close to the code, letting us know what’s most important. What’s changing is that we’re going to bring some order to those ideas. It all starts with the feature page.

Part 1: The Feature Page

A feature page is a basic one-page summary of a piece of work. It’s written before implementation work begins, and brings all the information about a feature together, including:

  • A summary of the feature’s motivation, goals and non-goals
  • Bugs tracking work items
  • Dependencies on other groups
  • The feature team (Developer, UX, Security, QA, Project Management, &c) and overall owner
  • Any UI designs, behaviour specs, test plans, and references necessary to make the implementation right, and usefully estimate its size

A feature page is more flexible than a bug for tracking these soft pieces. It introduces some maintenance cost for the feature owner, but the benefit is that every feature has a source of truth. Beyond the benefits this brings to engineering, it gives teams like QA, Security, Marketing, and Support a point source for the work they do for every feature we ship. Not having that source in the past has hurt us. Repeatedly, and significantly.

Part 2: Feature Tracking

When a new feature is picked up for work, the owner (not necessarily the main developer!) links to the feature from the tracking page. The tracking page transcludes each feature’s status line into an overall summary.

A given feature might move between releases on the tracking page as the realities of the feature’s size change; that’s fine. Having things on one page still lets us see at a glance what’s likely to make the next train, and the train after that. It helps us spot possible conflicts or danger spots earlier and lets people who care about different stages of the release focus their work. As this system starts to work, I can well imagine our development meetings re-orienting themselves to track this list.

Part 3: Feature Prioritization

Looking for a feature to work on? The product team is building a list with all of them. The feature list is, in a sense, the product team’s central deliverable: it maps our overall vision and priorities to a ranked list of feature work that embodies them. Start at the top of the list, work down until you find a good match for your skills and interests, poke the owner, and spin it up.

Part 4: Adding Features

The features on the list come from everywhere in Mozilla, as they always have. What’s new is that we collect them in one page; new features go into the inbox. Have an idea? Write up a feature page, add it to the inbox, and the product team will triage it into the right spot.

Of course, you can just do the work in a bug without any of this, but you do so at your own peril. Unlisted features have no priority, which means you’re back to contending for scarce resources. Writing the feature page is also an exercise in clarifying your thoughts, I don’t think the bar there is too high.

So to sum up…

I know, it’s a lot of words. And not every piece of work rises to the level of “Feature” and requires this overhead – straight up bug fixes rarely will, for instance. Nevertheless, I think the change is worth it. For me, ensuring we work on the right things, to say nothing of the benefits in terms of communication & coordination of work, are easily worth the cost. What do you think?

5 comments

  1. I think that it’s awesome, and couldn’t agree more that the biggest change is moving to a newer system like this with deliberation and understanding that it’s a work in progress which – like the very software we make – will improve over time based on experience and feedback.

    We’ve taken baby steps over the past five years, and this is a quantum leap. I applaud y’all for getting it done!

  2. This sounds like a big improvement over doing this kind of tracking (or trying to do parts of it) in bugzilla, so that’s great.

    The only worry I have is what happens to the stuff that already happened – things introduced in 3.6 or 4.0 that don’t have feature pages, but still have bugs. Could those have retrospective feature pages? Could something like UX’s “paper cuts” idea, or a memory use reduction or stability project have a feature page despite not being a “feature”?

    Otherwise this presumably only makes worse the problem that if a significant regression actually manages to ship, it becomes part of the baseline and loses any priority it might of had if it hadn’t been shipped.

    But this way of tracking features like this should mean that kind of problem happens less in future – that has to be good.

  3. This is a nice summary of the process, Johnath! Thanks for putting this up there. It’s a good resource I can point people to.

    Michael: some bugs will get fixed without feature pages (Firefox 5 had a lot of that, by virtue of being the first release going through this process).

    It is also quite reasonable to have a “papercuts” sort of feature that takes a collection of bugs that would represent a distinct improvement in the polish or usability of a part of Firefox. For example, there’s a feature listed (no feature page yet!) for “20 high priority polish bugs”:

    https://wiki.mozilla.org/Features/Firefox

    We still have a lot of feature pages to put together, but I do think that having this information concentration in one place is already helping.

  4. It’s an interesting use of a wiki, good luck. It’s confusing that the Rank P1 color is close to the Status Healthy color.

    A useful trick is to use {{Special:PrefixIndex/{{FULLPAGENAME}}/}} to show all subpages of a feature , e.g. https://wiki.mozilla.org/DevTools/Features. It’s unclear whether subpage hierarchy or category or both determines a feature’s classification.

    *If* Mozilla were to use the Semantic MediaWiki extension, you could autogenerate feature lists by querying for [[Category:Feature]] [[Category:Firefox]] [[ETA::FX5]] , instead of transcluding. But it means someone updating a feature page might accidentally push their feature into a tracking list, which depending on organizational politics is either a drawback or a plus 😉 SMW also lets you query information across feature pages, e.g see who’s overcommitted as [[Property:Lead developer]].

    FWIW, I helped One Laptop Per Child manage features in their wiki, e.g. http://wiki.laptop.org/go/Feature_roadmap/Activity_updater_improvements shows up in http://wiki.laptop.org/go/Feature_roadmap . As you can see they abandoned it when they downsized.

    MediaWiki is like a swiss army knife with many implements that you can use as hammers, assuming you treat each datum as a page titled “Nail” 🙂

  5. shouldn’t the following pages be restricted, to only let people edit them that do the actual triage?

    https://wiki.mozilla.org/Features/Release_Tracking
    https://wiki.mozilla.org/Features (the various sub-pages)