Features/Feature page documentation: Difference between revisions

Jump to navigation Jump to search
m
Line 7: Line 7:
{{RequiredLabel}}
{{RequiredLabel}}
=== Stage and Status ===
=== Stage and Status ===
Stage is one of:
Status can be one of:
* '''Draft''': default
; (blank): default - having a status doesn't make sense for all stages.  For example "Complete: Complete" is silly, but "Development: In progress" makes sense.
* '''Feature Inbox''': The feature page is ready to be triaged and prioritized by the Product team.
; In progress: Work on the current stage has been started.
* '''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.
; Complete: Work on the current stage is finished.
* '''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.
Stage can be one of:  
* '''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.
; Draft: default
* '''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.
; Feature Inbox: The feature page is ready to be triaged and prioritized by the Product team.
* '''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.
; 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.
* '''Landed''': The feature has landed.
; 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.
* '''Shipped''': The feature has been shipped as part of a final product.
; 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.
* '''Complete''': The feature team has done whatever follow-up or post-mortem work they feel necessary.  The end.
; 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.


=== Release target ===
=== Release target ===
canmove, Confirmed users, Bureaucrats and Sysops emeriti
6,906

edits

Navigation menu