Features/Planning and Tracking

We have put together a lightweight wiki-based system for listing, prioritizing, defining, and tracking new Firefox features towards helping with the new, faster release cadence.

This system currently has three parts, which I explain in some more detail below:

• The Feature Lists
• Feature Pages
• Release Tracking Page

A feature is a "shippable unit", a well-scoped and atomic piece of work that improves a part of Firefox. This is a smaller unit than what we normally think of as a feature, but conceptually larger than a typical bug fix.

Something like "Create a Home Tab as a Permanent App Tab" is a feature under this definition, whereas "App Tabs" is too large to be well-scoped. "App tab rendering glitch on OS X" is too small to be worth feature tracking, as it is really just fixing a flaw rather than adding to the product or changing how something behaves.

The initial Features list has been drawn from the Roadmaps and team priority lists, and will undergo regular prioritization review (initial prioritization still underway).

The list will constantly evolve as features are completed and removed, and new ones are added or reprioritized.

A Note on Prioritization: The current prioritization is incomplete, occasionally contradictory, and will also evolve as we go. The P1/P2/P3s are there simply as an initial attempt to sort things into "Super Important, Important, and Slightly Less Important" buckets. In the long term we want to avoid bucketing and make this list strictly rank-ordered. In the meantime, if you believe something has been woefully mis-prioritized, contact the listed owner of that item and we'll sort it out.

Every item on the Feature List has a corresponding Feature Page. This is where the Feature is defined, specified, staffed, and tracked during development.

Feature Managers

Each Feature Page's team list must specify a Feature Manager. The Feature Manager is the person who is responsible for driving a Feature to completion and ensuring that the Feature Pages are filled out and kept up to date as needed.

Each release gets a release tracking table, and each release tracking table is populated with the transcluded "status" lines of the Feature Pages that are currently under development and targeted for that release.

Release targets are just that: targets. If something is not ready in time for a release, it is very simple to move that status block into the next release's release tracker. The release tracker lets us track things which are likely to hit, they do not commit projects to merging before they're ready.

If you are actively working on something for Firefox, chances are good that it should have a Feature Page and should be on the Features list (see FAQ for caveats).

If your Feature doesn't have a Feature page

Every feature on the Feature List must have a Feature Page. Create one by going here and following the directions: Create new feature page.

If your Feature is not on the Feature List

If you have an item you would like to add to the Feature List, you must first create a Feature Page for it, including enough information in the page that the triage team will be able to understand what you're proposing.

Once you have a Feature Page filled out, you should change the "Stage" to "Feature Inbox". This will put the feature into the Inbox where a crack team of product people will triage and prioritize it. From there it will move into the Feature Lists.

Note: Anyone is welcome to propose a feature this way -- this is not restricted to particular people or teams.

If your Feature is not on the Release Tracking page

If your Feature isn't on the Release Tracking page and should be, contact Deb.

Why do we need to do this?

We always have more things that we want to do than people and time we have to do them. This system is a simple way for us to have a shared understanding of our priorities, where people are spending their time, how things are going, and what the various tradeoffs are if/when we have to make hard decisions about what to work on (and therefore what not to).

But what about this bugfix I'm working on?

Typical bugfixes do not need to have Feature pages or be tracked via the Release Tracking page, but pretty much everything else does. If you're not sure if your thing should have a Feature page, here are a few questions to ask:

1. Does it take more than one bug to accomplish?
2. Is it something that we would include in release notes and/or brag about?
3. Does it add to the product or change how the product behaves for users, web developers, or add-on developers?
4. Is it bigger than a breadbox?

If any of these answers is "yes", then you should create a feature page.

The Features List is missing something important!

Great - let us know. The product team owns the list and the prioritization, but we do not expect to be the source of every idea, we expect to be the clearinghouse bringing them all together and aligning them against our long term plans.

I am excited to start working on a feature, how do I start?

Ping the listed owner for that feature and let them know. The first step is to identify the team involved (Project Manager, Developer(s), QA lead, contacts from security, usability and elsewhere as appropriate), get it into the tracker with an appropriate estimate, and then start hacking.

If you have other questions, feedback, or concerns, please do not hesitate to contact Deb (deb@mozilla.com). We'll be working on evolving this system over time, so your feedback and ideas are incredibly valuable and appreciated.