Features/Feature page documentation
|
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. |
Future home for the new feature page notes
Contents
Basics
Feature name
Required Every feature needs a name.
The feature's name doesn't need to be long, but try to make it descriptive and in as plain English as possible. Avoid jargon or deeply technical terms where possible so folks in other departments (Products, Engagement, Press) will have some idea what the Feature is about.
Stage
Stage can be one of:
- Draft
- default
- Feature Inbox
- The feature page is ready to be triaged and prioritized by the Product team.
- On hold
- The feature page has been triaged but not prioritized by the Product team for whatever reason -- if you are involved in the creation of the feature page, you will be contacted by the team.
- Definition
- This is where a feature is born and defined. If you would like to propose a new Feature, start by writing up a clear overview and a by defining the feature’s intended users and use cases. Where possible, you are encouraged to add to the list of the dependencies and requirements, but the Product team will help flesh out these parts if you don’t include them.
- Design
- In this stage, Products, Engineering, UX, and/or User Research work together to finalize the feature’s functional specification and, if needed, the user experience design.
- Planning
- With the requirements and design clarified and approved, the feature moves into the planning stage, where the Engineering team sorts out the overall technical approach that will be taken, and other stakeholder teams (Security, Privacy, QA, Accessibility, Localization, etc.) have the opportunity to review the feature in detail. This stage is complete when all stakeholder teams finish their reviews and are comfortable with the requirements, design, and plan for implementation.
- Development
- This is where coding begins and activity for feature development moves into Bugzilla. Detailed progress tracking will not be done on the wiki — that should all happen in Bugzilla, and will not be replicated on the feature pages. Product or project managers are responsible for updating the status on the feature pages if and when needed.
- Release
- In this stage the team documents the final checklist of everything the team feels should happen before a feature can land. Over time, we’ll develop a standardized checklist for this, but we’ll sort that out as we go. For now, the team will create their own checklist and ensure that everything on it is complete before the feature lands.
- Landed
- The feature has landed.
- Shipped
- The feature has been shipped as part of a final product.
- Complete
- The feature team has done whatever follow-up or post-mortem work they feel necessary. The end.
Status
Status can be one of:
- (blank)
- default - having a status doesn't make sense for all stages. For example "Complete: Complete" is silly, but "Development: In progress" makes sense.
- In progress
- Work on the current stage has been started.
- Complete
- Work on the current stage is finished.
Release target
When you know (or think you know) which train the feature is going to be on, add that information here. The format should be basic, ie: "Firefox 7", as we use this value in queries and it will need to match.
This field has an autocomplete option that will show you all of the existing values for Release Target as you type.
Health
Health can be one of:
- OK
- Standard operating mode. If all is going as expected and there are no obstacles to progressing on work, the feature's health is "OK".
- Blocked
- If there is something blocking progress on this feature for whatever reason, select this value.
- At Risk
- If this feature is targeted for a particular release but is at risk of missing that release, select this value.
If you change the health value for a feature, please explain the situation in the "Status note" so people who are tracking the feature have some idea of what's going on. It doesn't need to be a really long note, just a quick summary is fine -- folks can follow up with you if needed.
Status note
A quick summary of the current status/stage or next steps required to progress.
This note should be succinct but should also include enough information that the people tracking the feature can get a rough idea of what's going on with a feature.
Team
DRI
"Directly Responsible Individual": Whomever is responsible for driving this feature to completion.
Open issues/risks
Any open issues that need to be addressed, and known or suspected risks related to this feature.
Stage 1: Definition
Feature overview
Required Overview description of the feature, motivation for the feature, goals, why it's important.
Users & use cases
Required A clear definition of the target users/audience and the use cases that we want to support, for either end-users or developers.
Dependencies
Defining giver dependencies and taker dependencies so you know who owes to whom what and when.
Requirements
A list of things that the feature should do (must-haves and nice-to-haves) for users and/or developers. This should not include implementation decisions or options, but should include performance/latency/SLA/responsiveness requirements.
Non-goals
Anything we're specifically not trying to do with this particular iteration of a feature.
Stage 2: Design
Functional specification
What the feature will do to satisfy the requirements, in written form.
User experience design
Designs, interactions, etc., mainly in visual form, if relevant.
Stage 3: Planning
Implementation plan
Summary of the high-level approach to be taken.
Reviews
Have the various teams been contacted about this feature? Are there risks; has the design been reviewed; what needs to be changed before we proceed?
Stage 4: Development
Implementation
Primarily links to relevant bugs -- we don't try to track the detailed progress here, that should happen in bugzilla.
Stage 5: Release
Landing criteria
Final checklist for everything the feature team feels should happen before a feature can land -- could be a scalability model, security code review, etc. Will eventually develop a standard table for this.
Feature details
Priority
The basic priority buckets:
- Unprioritized
- The Product team hasn't yet set a priority for this feature.
- P1
- This feature is very important and should be started as soon as resources are available.
- P2
- This feature is important, but it doesn't need to be started right away.
- P3
- This feature is important, but depends on another feature to be completed first, or is something we are hoping to get a little further down the road.
Roadmap
Not every feature will be associated with a particular Roadmap, but those that are should have that Roadmap specified here.
If the dropdown list doesn't include the name of the Roadmap you need, please contact Deb, and she'll help get that added to the form.
Feature List
Feature list is one of:
- Desktop
- Mobile
- Platform
- Services
- Jetpack
- Firefox Home
- Other
If you're not sure which feature list a feature should be on, either make your best guess or leave this value blank, and we'll sort it out in triage.
Engineering Team
The primary team that will be implementing this feature. If there are multiple teams involved, pick whichever will need to work on it first/next.
Team status notes
Teams are welcome to use these fields however they see fit. Both fields can be used in queries to generate lists on other wiki pages. If you would like help or have questions, please contact Deb.
