User:Dria/Feature Page HOWTO

How to fill out a Feature Page (the new version!)

Creating a new feature page

To create a new feature page, simply go to the Feature Page Structure page, click "edit", copy the contents of that page, then paste those contents into a new wiki page. (Do not change the Feature Page Structure page directly.)

If you don't know how to start a new wiki page, see the Starting a new page documentation at Mediawiki.

Feature Template Block

At the top of each feature page you should have a template to fill out that includes:

• feature name: the name of the feature
• feature of: one of
  • "Desktop"
  • "Mobile"
  • "Platform"
  • "Services"
  • "Other"
• team: the name of the engineering team that will be doing the primary work on this feature
• feature manager: the name of the person who is responsible for driving this feature to completion -- often the product or project manager
• priority: one of
  • "Px" (unprioritized)
  • "P1"
  • "P2"
  • "P3"
• health: one of
  • "healthy"
  • "blocked"
  • "atrisk"
• stage: one of
  • "Not started"
  • "Definition"
  • "Design"
  • "Implementation"
  • "Review"
  • "Testing"
  • "Release"
  • "Complete"
• eta: YYYY/MM/DD format date for completion of the current stage
• status: Succinct summary of the current state of the feature's progress.
• target: "Firefox #"
• sdr (Security Design Review): one of "TBD", "N", "P", or "C" (not required, pending, complete)
• sir (Security Implementation Review): one of "TBD", "N", "P", or "C" (not required, pending, complete)
• pr (Privacy Review): one of "TBD", "N", "P", or "C" (not required, pending, complete)
• l10nr (Localization Review): one of "TBD", "N", "P", or "C" (not required, pending, complete)
• lr (Legal Review): one of "TBD", "N", "P", or "C" (not required, pending, complete)
• udocs (User Docs): one of "TBD", "N", "P", or "C" (not required, pending, complete)
• ddocs (Developer Docs): one of "TBD", "N", "P", or "C" (not required, pending, complete)

Required Sections

There are two sections that must be filled in before the feature page is considered complete enough to triage, prioritize, and add to the feature lists.

• Summary: This is a succinct summary of the feature and its overall value and importance to the product. This should clearly explain what the feature is, and why we want to implement it.

• Use Cases: Both user-facing and developer-facing features must have one or more clearly defined use cases. These will help us understand how to best prioritize the feature against other work.

Other Sections

• Team: the team list should include everyone who will be working on or responsible for some aspect of the feature from beginning through release. Please make the team list as comprehensive as possible, and please ensure that everyone on the list knows that they're on the list.

• Release requirements: Complete checklist of items that must be satisfied before we can call this feature "done".

• Related Bugs & Dependencies: Links to any relevant bugs, feature pages for features that depend on this, and any notes about things that depend on this, etc.

• Risks: Identify, prioritize, track and communicate any risks associated with this feature/project.

• Designs: Any and all mockups, design specs, tech specs, etc. Either inline or linked to.

• Test Plans: Any and all test plans and strategies. Either inline or linked to.

• Non-goals: Things we are specifically not doing or building as part of this feature.

But what about...?

You're welcome to add any other information to the Feature page you like, and use it however you need. So long as the Feature Template Block is filled in and kept up to date, and as long as you provide a good Summary and Use Cases, you're free to use the feature pages as you see fit.