Features/Lifecycle of a feature

How to create a Feature Page (aka: Lifecycle of a Feature)

I recently blogged about our new approach to Firefox planning and tracking, the heart of which is the "Feature Page" -- the single wiki page in which a feature is defined, specified, staffed and tracked throughout development. The following is a more detailed explanation of what Feature Pages are and how to use them.

This is split into three chunks -- how to create the page, how to fill out the page, and how to use the page from feature definition through Firefox release.

If you have any questions about anything here, please contact Deb.

Creation & Proposal

Features have to go through an initial proposal and triage process before they're part of our official product development plans. Everyone is welcome to propose new features in this way:

• Create a new wiki page and copy/paste the Feature Page Structure page into it. If you don't know how to create a wiki page, read Starting a new page.
• Fill in as much of the Feature Page as you can. At very least you must fill in the:
  • Status table, including Feature name, current status ("Not started." is fine if true), and your name as the "Owner" for now.
  • Summary: should be succinct, but should include enough information and detail that the Features triage team will know what you're proposing and how to prioritize it against other work. Shouldn't be massive, but should be more than a sentence. Please do not just link to a bug and leave it at that -- take the time to summarize and explain it.
  • Team list: Fill in as much of this as you can, but we'll revisit this later.
  • Anything else you can fill out in the page would be great, but doesn't have to be done at this point.
• Add your Feature to the }Features Inbox.

Triage & Prioritization

At this point, your Feature is in the triage queue, and will be looked at by the triage team within a week (currently Mondays). At this point there are three possible fates for your feature:

1) The triage team decides that your Feature is not something we want to do, and it is rejected. 2) The triage team bounces the Feature back to you for more information, rescoping, or some other refinement. If this happens, you should revise/refine your feature proposal and re-submit it to the inbox. If you have questions about this, contact Deb and she'll help you get it sorted out. 3) The triage team accepts your Feature as proposed, prioritizes it, and adds it to the appropriate Feature List. At this point, you should carry on with filling out the feature page with as much detail as possible.

Fleshing out the bones

One of the most important parts of the feature page is the team list. This list should include everyone who is working on or will work on this feature, including QA, Privacy, Security, L10N, etc. It is at this point that you should bring your feature to the attention of everyone and anyone who may need to be involved.

Team List (required)

• Feature Manager (required): This should be the person who is responsible for doing the day-to-day work of driving the feature to completion and updating the feature page. When the release drivers or product management team has questions about the current state of a feature, the Feature Manager is who they will contact.
• Lead Developer (required): The primary engineer for the Feature. This is whomever we should talk to if we need to ask someone about technical or engineering-related aspects of the project.
• Product Manager (required): The PM responsible for whatever area of the world this Feature falls within. This is whoever we should talk to if we need to ask someone for product-related guidance or decisions.
• QA (required): Contact person for the QA team responsible for this product or this part of the product. When you add a QA contact to this list, please ensure that you actually tell them that they're on the list.
• UX: Not every feature will require UX work, but if you are not sure, you should contact the UX team and ask. If UX work is required, add the UX team contact person's name here.
• Accessibility: Contact the Accessibility team so they can evaluate your feature and decide whether it will need an accessibility review. If it does, add the Accessibility team contact person's name here.
• Security: Contact the Security team so they can evaluate your feature and decide whether it will need a security review. If it does, add the Security team contact person's name here.
• Privacy: Contact the Privacy team so they can evaluate your feature and decide whether it will need a privacy review. If it does, add the Privacy team contact person's name here.

The other stuff (not required, but useful!)

While we recommend that you take the time to think through and fill in the other sections in the Feature page, we also recognize that every Feature and Feature team is different and are going to need different things and work in different ways.

It is largely up to the Feature Manager and the Product Manager to decide what other parts of the Feature page they want to fill out and use throughout development.

Design & Specification

Before coding can begin, the Feature design and specs (both UX and technical) should be finished and either included in the Feature page or linked to from the Feature page.

This is the phase in which the UX team and the User Research team do their work if they are involved.

Please be sure to keep the status block of your Feature page updated throughout this process.

Implementation & Tracking

When the designs are complete, the feature should be completely ready for engineering to pick it up and begin implementation. When implementation begins:

1) The "Rank" column for that Feature on the Feature List should be updated to "In Progress" using the In Progress template. 2) The Status block for the Feature should be transcluded into the Release Tracking page.

When implementation starts, most activity will likely move to bugs, which is fine. We do ask that you update the status block of the Feature page at least weekly if not more frequently. We need to be able to track overall status without having to dig through the bugs. Updates (or making sure someone makes updates) is the responsibility of the Feature Manager.

Landing, Channels & Release

TBD