User:Dria/Feature Page HOWTO

From MozillaWiki
Jump to: navigation, search
DRAFT
I am in the process of changing over the Feature Pages to use this new system. Not yet complete.

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.)

Required The only parts you have to change are flagged as "Required" with the green label. Once you fill in those bits, you are welcome to remove the green labels.

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

The Feature Infobox

There's a handy infobox at the top of each Feature page. When you're creating a new feature page, there are only a few values you have to change (flagged as "Required" below). The more info you can provide, the better, of course:

Required feature name
The name of the feature
Required feature list
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 (default, unprioritized), P1, P2, P3
health
one of "Healthy", "Blocked", "At Risk"
stage
one of, "Not started" (default), "Inbox", "Triaged", "In Progress", "Nightly", "Aurora", "Beta", "Released"
eta
estimated date for completion of the current stage (YYYY/MM/DD format)
status
Succinct summary of the current state of the feature's progress. (1-2 sentences)
target
target product release, ie: "Firefox 7"
sdr (Security Design Review)
one of "TBD" (default), "N", "P", or "C" (not required, pending, complete)
sir (Security Implementation Review)
one of "TBD" (default), "N", "P", or "C"
pr (Privacy Review)
one of "TBD" (default), "N", "P", or "C"
l10nr (Localization Review)
one of "TBD" (default), "N", "P", or "C"
lr (Legal Review)
one of "TBD" (default), "N", "P", or "C"
udocs (User Docs)
one of "TBD" (default), "N", "P", or "C"
ddocs (Developer Docs)
one of "TBD" (default), "N", "P", or "C"

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.

  • Required 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.
  • Required 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.
  • Required Team: Please fill out at least the "Proposed by:" (that's you). The rest of team list should include everyone who will be working on or is responsible for some aspect of the feature from beginning through release.

Other Sections

  • 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.