Features/Planning and Tracking

What is this?

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:

What is a "feature"?

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 Features List

The initial Features list has been drawn from the Roadmap documents and team priority lists, and will undergo regular prioritization review (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.

Feature Pages

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

The feature page includes a "status" table at the top which should be updated anytime the status of the project changes. This is transcluded into the Flight Tracker pages, where we'll be tracking overall progress on items slated for the next release or three.

The status line at the top is not optional -- we actually need that there and updated as frequently as possible.

 
^ not optional

Feature pages can be hacked however it makes sense for a particular feature so long as the basic information is available on them. Keeping the feature page in general, and the status in particular, up to date is the responsibility of each feature's Feature Manager.

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.

Flight Tracker Page

Each release gets a flight tracker table, and each flight tracker table is populated with the transcluded "status" lines of the Feature Pages that are currently in-flight 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 flight tracker. The flight tracker lets us track things which are likely to hit, they do not commit projects to merging before they're ready.

Next steps?

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 is not on the Feature List
You may add your feature to the bottom of the table in the appropriate section, but please do not set a priority if you do so. Once per week we (to be defined) will go through the unprioritized items that have been added to the lists and prioritize them accordingly.
Alternately, find the relevant Product Manager or Deb and we can sort out getting your feature added and prioritized.
If your Feature doesn't have a Feature page
Copy and paste the basic Feature Page Structure into a new page, fill out the basics, then link to it from the Features list. Please be sure to specify a Feature Manager in the team list.
If your Feature is not on the Flight Tracker
If your Feature isn't on the Flight Tracker and should be, contact Deb.

FAQs

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?
Single bugfixes do not need to have Feature pages or be tracked via the Flight Trackers. The current working rule-of-thumb is that if something requires more than two bugs to define and track, it should probably have a Feature Page and be tracked using this system.
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.

Questions & Feedback

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.