Features/Feature page documentation: Difference between revisions
m (Created page with "Future home for the new feature page notes == Status == === Stage === === Version === === Health === === Status note === == Team == === Feature manager === == Open issues/risk...") |
mNo edit summary |
||
| Line 6: | Line 6: | ||
=== Health === | === Health === | ||
=== Status note === | === Status note === | ||
A quick note about current status/stage or next steps required to progress. | |||
== Team == | == Team == | ||
| Line 11: | Line 12: | ||
== Open issues/risks == | == Open issues/risks == | ||
Any open issues that need to be addressed, and known or suspected risks related to this feature. | |||
== Stage 1: Definition == | == Stage 1: Definition == | ||
=== Feature overview === | === Feature overview === | ||
Overview description of the feature, motivation for the feature, goals, why it's important. | |||
=== Users & use cases === | === Users & use cases === | ||
A clear definition of the target users/audience and the use cases that we want to support, for either end-users or developers. | |||
=== Dependencies === | === Dependencies === | ||
Defining giver dependencies and taker dependencies so you know who owes to whom what and when. | |||
=== Requirements === | === 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 === | === Non-goals === | ||
Anything we're specifically not trying to do with this particular iteration of a feature. | |||
== Stage 2: Design == | == Stage 2: Design == | ||
=== Functional specification === | === Functional specification === | ||
What the feature will do to satisfy the requirements, in written form. | |||
=== User experience design === | === User experience design === | ||
Designs, interactions, etc., mainly in visual form, if relevant. | |||
== Stage 3: Planning == | == Stage 3: Planning == | ||
=== Implementation plan === | === Implementation plan === | ||
Summary of the high-level approach to be taken. | |||
=== Reviews === | === Reviews === | ||
Has 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 == | == Stage 4: Development == | ||
=== Implementation === | === Implementation === | ||
Primarily links to relevant bugs -- we don't try to track the detailed progress here, that should happen in bugzilla. | |||
== Stage 5: Release == | == Stage 5: Release == | ||
=== Landing criteria === | === 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 == | == Feature details == | ||
Revision as of 15:28, 22 June 2011
Future home for the new feature page notes
Status
Stage
Version
Health
Status note
A quick note about current status/stage or next steps required to progress.
Team
Feature manager
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
Overview description of the feature, motivation for the feature, goals, why it's important.
Users & use cases
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
Has 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.