Difference between revisions of "Blueprints"
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
− | + | Launchpad blueprints are used to track the implementation of significant features in OpenStack. Keeping their status current is critical to the success of the release and the project as a whole. It avoids unnecessary reporting, pings and discussions, and keeps everyone on the same page. | |
− | + | = Blueprints reference = | |
− | + | Here are the different fields available in Launchpad blueprints, and how we use them within the OpenStack project. | |
− | |||
− | + | === Specification link === | |
+ | URL to an additional document, potentially describing the design and implementation details. | ||
− | == | + | === Priority === |
− | + | PTLs use priority to communicate how important a given feature is to the success of the next release. | |
− | == | + | {| border="1" cellpadding="2" cellspacing="0" |
+ | | ''Essential'' | ||
+ | |- | ||
+ | | ''High'', ''Medium'' and ''Low'' | ||
+ | |- | ||
+ | | ''Undefined'' | ||
+ | |} | ||
− | + | === Definition === | |
− | + | PTLs may ask you to use the definition status during the planning phase of the [[ReleaseCycle]]. | |
− | = Discussion | + | {| border="1" cellpadding="2" cellspacing="0" |
+ | | ''New'' | ||
+ | |- | ||
+ | | ''Discussion'' | ||
+ | |- | ||
+ | | ''Drafting'' | ||
+ | |- | ||
+ | | ''Review'' | ||
+ | |- | ||
+ | | ''Pending approval'' | ||
+ | |- | ||
+ | | ''Approved'' | ||
+ | |- | ||
+ | | ''Superseded'' | ||
+ | |- | ||
+ | | ''Obsolete'' | ||
+ | |} | ||
− | + | === Implementation === | |
− | + | Use this status to indicate the degree of completion of your blueprint. This is mandatory. | |
− | + | {| border="1" cellpadding="2" cellspacing="0" | |
+ | | ''Unknown'' | ||
+ | |- | ||
+ | | ''Not started'' | ||
+ | |- | ||
+ | | ''Started'' | ||
+ | |- | ||
+ | | ''Blocked'' | ||
+ | |- | ||
+ | | ''Slow progress'' | ||
+ | |- | ||
+ | | ''Good progress'' | ||
+ | |- | ||
+ | | ''Beta available'' | ||
+ | |- | ||
+ | | ''Needs code review'' | ||
+ | |- | ||
+ | | ''Implemented'' | ||
+ | |} | ||
− | + | Extra statuses: | |
− | + | {| border="1" cellpadding="2" cellspacing="0" | |
+ | | ''Informational'' | ||
+ | |- | ||
+ | | ''Deferred'' | ||
+ | |- | ||
+ | | ''Needs infrastructure'' | ||
+ | |- | ||
+ | | ''Deployment'' | ||
+ | |} | ||
− | + | === Series goal === | |
+ | The release series (Essex, Folsom...) targeted by this blueprint. This is used by the PTL to build the roadmap for a given release. | ||
− | + | === Approver === | |
+ | The PTL for the project. | ||
− | == | + | === Drafter === |
+ | The person responsible for the planning phase on this blueprint. | ||
− | == | + | === Assignee === |
+ | The person responsible for implementing the blueprint. This is mandatory. | ||
− | + | === Milestone target === | |
+ | The milestone the blueprint should be completed by. This is mandatory. | ||
− | + | === Related branches === | |
+ | Not used. | ||
− | + | === Related bugs === | |
+ | Bugs related to this blueprint, if any. | ||
− | + | === Sprints === | |
+ | Not used. | ||
− | + | === Feedback requests === | |
+ | Not used. | ||
− | + | === Whiteboard === | |
+ | Free-form notes. If the blueprint implementation is blocked, this should state the reason why. Gerrit will add notes about corresponding reviews in this field. | ||
− | [[ | + | === Dependency tree === |
+ | Dependencies between blueprints. If one blueprint needs to be delivered before this one, this needs to be recorded here. | ||
+ | |||
+ | = Blueprints lifecycle = | ||
+ | |||
+ | === Creation === | ||
+ | |||
+ | If you intend to work on a given feature, you should create a blueprint for that. Describe the feature summarily in the blueprint itself, and link to another document (using the specification link) if you have more. | ||
+ | |||
+ | Note that you may track the peer-review of your blueprint using the ''Drafter'' and ''Definition'' fields. | ||
+ | |||
+ | Once it is ready for PTL review, you should set; | ||
+ | |||
+ | * Approver: <the PTL for the project> | ||
+ | * Assignee: <who will do the work> | ||
+ | * Series goal: Proposed for <the current development series> | ||
+ | * Milestone: When you think your work will be proposed for merging | ||
+ | |||
+ | === Inclusion in the release roadmap (PTLs) === | ||
+ | |||
+ | The PTL reviews the blueprint, then may include it as a release goal: | ||
+ | |||
+ | * Definition: ''Approved'' | ||
+ | * Series goal: Accepted for <the current development series> | ||
+ | * Priority: <blueprint priority> (see above) | ||
+ | |||
+ | === During development (assignee) === | ||
+ | |||
+ | The "Implementation" field should reflect progress in your work: | ||
+ | |||
+ | * Implementation: <degree of completion> (see above) | ||
+ | |||
+ | Please update the implementation status regularly to avoid being pinged about it :) | ||
+ | |||
+ | === When merged (assignee) === | ||
+ | |||
+ | When the work is fully merged, finalize the spec by setting: | ||
+ | |||
+ | * Implementation: ''Implemented'' | ||
+ | |||
+ | = See also = | ||
+ | * [[ReleaseCycle]] | ||
+ | * [[BugsLifecycle]] |
Revision as of 09:36, 4 June 2012
Launchpad blueprints are used to track the implementation of significant features in OpenStack. Keeping their status current is critical to the success of the release and the project as a whole. It avoids unnecessary reporting, pings and discussions, and keeps everyone on the same page.
Blueprints reference
Here are the different fields available in Launchpad blueprints, and how we use them within the OpenStack project.
Specification link
URL to an additional document, potentially describing the design and implementation details.
Priority
PTLs use priority to communicate how important a given feature is to the success of the next release.
Essential |
High, Medium and Low |
Undefined |
Definition
PTLs may ask you to use the definition status during the planning phase of the ReleaseCycle.
New |
Discussion |
Drafting |
Review |
Pending approval |
Approved |
Superseded |
Obsolete |
Implementation
Use this status to indicate the degree of completion of your blueprint. This is mandatory.
Unknown |
Not started |
Started |
Blocked |
Slow progress |
Good progress |
Beta available |
Needs code review |
Implemented |
Extra statuses:
Informational |
Deferred |
Needs infrastructure |
Deployment |
Series goal
The release series (Essex, Folsom...) targeted by this blueprint. This is used by the PTL to build the roadmap for a given release.
Approver
The PTL for the project.
Drafter
The person responsible for the planning phase on this blueprint.
Assignee
The person responsible for implementing the blueprint. This is mandatory.
Milestone target
The milestone the blueprint should be completed by. This is mandatory.
Related branches
Not used.
Related bugs
Bugs related to this blueprint, if any.
Sprints
Not used.
Feedback requests
Not used.
Whiteboard
Free-form notes. If the blueprint implementation is blocked, this should state the reason why. Gerrit will add notes about corresponding reviews in this field.
Dependency tree
Dependencies between blueprints. If one blueprint needs to be delivered before this one, this needs to be recorded here.
Blueprints lifecycle
Creation
If you intend to work on a given feature, you should create a blueprint for that. Describe the feature summarily in the blueprint itself, and link to another document (using the specification link) if you have more.
Note that you may track the peer-review of your blueprint using the Drafter and Definition fields.
Once it is ready for PTL review, you should set;
- Approver: <the PTL for the project>
- Assignee: <who will do the work>
- Series goal: Proposed for <the current development series>
- Milestone: When you think your work will be proposed for merging
Inclusion in the release roadmap (PTLs)
The PTL reviews the blueprint, then may include it as a release goal:
- Definition: Approved
- Series goal: Accepted for <the current development series>
- Priority: <blueprint priority> (see above)
During development (assignee)
The "Implementation" field should reflect progress in your work:
- Implementation: <degree of completion> (see above)
Please update the implementation status regularly to avoid being pinged about it :)
When merged (assignee)
When the work is fully merged, finalize the spec by setting:
- Implementation: Implemented