Features/Lifecycle of a feature

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

(This is so not done.)

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

The Really Short Version

Here's the lifecycle of a feature in a nutshell:

1. You create a Feature Page
2. You add that Feature to the Features Inbox
3. Product Team triages the Inbox, and adds your Feature to the Feature List
4. Feature team fleshes out, designs, and specs the Feature
5. Feature Manager contacts Accessibility, Security, Privacy, QA, and Feedback teams to initiate those planning/review processes
6. Engineering team starts implementation of the Feature and adds it to the Release Tracking page
7. Engineering team completes and lands the Feature (Nightlies)
8. Accessibility, Security, and Privacy teams complete their reviews
9. QA team initiates final testing
10. Feedback team starts gathering feedback for this Feature (continues through release)
11. Feature moves to Aurora
12. Feature moves to Beta
13. Feature is released

For more detail, read on...

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:

1. 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.
2. Fill in as much of the Feature Page as you can. At very least you must fill in the:
   1. Status table, including Feature name, current status ("Not started." is fine if true), and your name as the "Owner" for now.
   2. 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.
   3. Use cases: both user-facing and developer-facing features must have use cases defined before a Feature is submitted to the Inbox, as this is how the Product Team knows what your feature is about and figures out how it should be prioritized. If you do not include use cases in the initial Feature page write up, your Feature will be bounced back to you until you include them.
   4. Team list: Fill out as much of this as you can, and make sure that the people on the list know that they're on the list.
   5. Anything else you can fill out in the page would be great, but doesn't have to be done at this point.
3. 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.

Use Cases (required)

Both user-facing and developer-facing features need to have use cases defined prior to a Feature being submitted to the Inbox. This is how the Product Team knows what a feature is about and how they figure out how to prioritize it. Without uses cases, your feature will be bounced back to you until those are defined.

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