Difference between revisions of "ProductTeam/Development Proposals"
(→Conditions For Movement of User Story) |
|||
| (12 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Development Proposals == |
| − | The Product Working Group discusses proposals, both, internally and externally using user stories. The | + | The Product Working Group discusses proposals, both, internally and externally using Development Proposals (formerly known as "user stories"). The Development Proposals are created using a [https://github.com/openstack/development-proposals/blob/master/development-proposal-template.rst standard template] which is located on the [https://github.com/openstack/development-proposals/ Product WG Repository]. The process for proposing and, eventually, implementing Development Proposals is depicted in figure 1.1. The primary source for information on Product WG Development Proposals is our [http://specs.openstack.org/openstack/development-proposals/ specs page]. |
| − | This [https://github.com/openstack/ | + | This [https://github.com/openstack/development-proposals/blob/master/doc/source/workflow/taxonomy.rst taxonomy] shows more details on the mapping on product WG mapping to agile terminology. |
| − | === | + | === Development Proposal Workflow === |
| − | <center>[[File: | + | <center> |
| − | + | [[File:Development Proposal Workflow.png|center|Development Proposal Workflow]] Figure 1.1 Development Proposal Workflow | |
| + | </center> | ||
| − | The workflow covers the proposal, refinement, acceptance, and implementation of | + | The workflow covers the proposal, refinement, acceptance, and implementation of a Development Proposal. Anyone is allowed to post a Development Proposal to the [https://github.com/openstack/development-proposals/tree/master/development-proposals/proposed proposed folder] in the repository. |
| − | <br> | + | <br><br> |
| − | ==== Possible Statuses for | + | ==== Gap and Overlap Analysis ==== |
| − | <b>Proposed:</b> | + | The team must conduct a technical gaps and overlaps analysis once a Development Proposal concept has been validated and any overlaps/conflicts with other proposed Development Proposals have been remediated. The Development Proposal owner and a technical SME will schedule a cross-project concept review meeting with the CPSL (cross project spec liaisons) from projects that would require blueprints/specs resulting from the Development Proposal. This meeting will be used by the team to validate the approach/concept, determine whether any proposed Development Proposals have to be deferred based on prior work inside the project(s), and the best way to proceed based on the outcome. |
| − | <b>Cross Project Spec Created:</b> Once the | + | <br><br> |
| − | <b>Cross Project Spec Accepted:</b> This is a | + | |
| + | ==== Implementation Plan ==== | ||
| + | The result from the gaps analysis meetings is an implementation plan. The implementation plan is not a required artifact and can be conveyed verbally or captured in other artifacts (such as the Development Proposal priorities or Development Proposal tracker). The goal of the implementation plan is to agree upon the next steps for a given Development Proposal whether that includes creating project level specs/blueprints, cross-project spec(s), or a new OpenStack project. The implementation plan is to ensure that all parties agree upon the next steps (this includes the Development Proposal owner, Development Proposal technical SME(s), and cross-project spec liaisons for the relevant projects). | ||
| + | <br><br> | ||
| + | |||
| + | ==== Possible Statuses for Development Proposals ==== | ||
| + | <b>Proposed:</b> Development Proposals are first submitted as a patch to this location in the repository. In this phase, the Development Proposal will be validated against the template (e.g. all mandatory sections are filled out properly) and the concept will also be discussed using gerrit comments against the change. The author/owner will should also submit new patch-sets to refine the Development Proposal based on the discussion. The change will not be merged (e.g. visible on the [http://specs.openstack.org/openstack/openstack-user-stories/ specs page]) until the Development Proposal has reached a point where the concept is considered validated by the team.<br><br> | ||
| + | <b>Cross Project Spec Created:</b> Once the Development Proposal is ready for community discussion, the Development Proposal owner will submit a change to the [https://github.com/openstack/openstack-specs cross-project specs repository] and update the Development Proposal in the "proposed" folder with a link to the cross-project spec review. The Development Proposal owner will also create an initial [https://github.com/openstack/development-proposals/blob/master/doc/source/tracker_overview.rst Development Proposal tracker] using the [https://github.com/openstack/development-proposals/blob/master/tracker/sample-tracker.json Development Proposal tracker template] with only the Development Proposal related fields completed.<br><br> | ||
| + | <b>Cross Project Spec Accepted:</b> This is a Development Proposal that has now become an accepted (merged) cross-project spec and is ready for an implementation plan (which includes component level blueprints and socialization with project teams). The Development Proposal owner, at this phase, will update the Development Proposal in the "proposed" to include a link to the actual cross-project spec (replacing the "review" link that was entered in the previous phase). The Development Proposal tracker should also be updated to include the cross-project related fields and any project-level specs/blueprints information as it becomes available.<br> | ||
<br> | <br> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | === | + | ==== Conditions For Movement of Development Proposal ==== |
| − | == | + | <b>Development Proposal Idea -> Proposed Change/Patch:</b> Anyone can submit a Development Proposal to this folder, this is the starting point for Development Proposals.<br><br> |
| − | + | <b>Review Proposed -> Merge Proposed:</b> The Development Proposal must meet template standards (e.g. all mandatory sections completed) and the concept has been refined by the Product WG through the gerrit review process.<br><br> | |
| − | + | <b>Merged Proposed -> Cross Project Spec Change/Patch:</b> A Development Proposal owner must be identified at this point and they are responsible for creating the cross-project spec submission. The Development Proposal owner will also change the "cross project spec link:" to "ready to submit" in a single-line change to the proposed Development Proposal, this indicates to the Product WG that this Development Proposal is about to be submitted for review by the technical community/cross project team. An initial tracker for the Development Proposal must also be created by the Development Proposal owner so the OpenStack community can track the status of the Development Proposal moving forward.<br><br> | |
| − | |||
Latest revision as of 20:30, 7 May 2017
Contents
Development Proposals
The Product Working Group discusses proposals, both, internally and externally using Development Proposals (formerly known as "user stories"). The Development Proposals are created using a standard template which is located on the Product WG Repository. The process for proposing and, eventually, implementing Development Proposals is depicted in figure 1.1. The primary source for information on Product WG Development Proposals is our specs page.
This taxonomy shows more details on the mapping on product WG mapping to agile terminology.
Development Proposal Workflow
The workflow covers the proposal, refinement, acceptance, and implementation of a Development Proposal. Anyone is allowed to post a Development Proposal to the proposed folder in the repository.
Gap and Overlap Analysis
The team must conduct a technical gaps and overlaps analysis once a Development Proposal concept has been validated and any overlaps/conflicts with other proposed Development Proposals have been remediated. The Development Proposal owner and a technical SME will schedule a cross-project concept review meeting with the CPSL (cross project spec liaisons) from projects that would require blueprints/specs resulting from the Development Proposal. This meeting will be used by the team to validate the approach/concept, determine whether any proposed Development Proposals have to be deferred based on prior work inside the project(s), and the best way to proceed based on the outcome.
Implementation Plan
The result from the gaps analysis meetings is an implementation plan. The implementation plan is not a required artifact and can be conveyed verbally or captured in other artifacts (such as the Development Proposal priorities or Development Proposal tracker). The goal of the implementation plan is to agree upon the next steps for a given Development Proposal whether that includes creating project level specs/blueprints, cross-project spec(s), or a new OpenStack project. The implementation plan is to ensure that all parties agree upon the next steps (this includes the Development Proposal owner, Development Proposal technical SME(s), and cross-project spec liaisons for the relevant projects).
Possible Statuses for Development Proposals
Proposed: Development Proposals are first submitted as a patch to this location in the repository. In this phase, the Development Proposal will be validated against the template (e.g. all mandatory sections are filled out properly) and the concept will also be discussed using gerrit comments against the change. The author/owner will should also submit new patch-sets to refine the Development Proposal based on the discussion. The change will not be merged (e.g. visible on the specs page) until the Development Proposal has reached a point where the concept is considered validated by the team.
Cross Project Spec Created: Once the Development Proposal is ready for community discussion, the Development Proposal owner will submit a change to the cross-project specs repository and update the Development Proposal in the "proposed" folder with a link to the cross-project spec review. The Development Proposal owner will also create an initial Development Proposal tracker using the Development Proposal tracker template with only the Development Proposal related fields completed.
Cross Project Spec Accepted: This is a Development Proposal that has now become an accepted (merged) cross-project spec and is ready for an implementation plan (which includes component level blueprints and socialization with project teams). The Development Proposal owner, at this phase, will update the Development Proposal in the "proposed" to include a link to the actual cross-project spec (replacing the "review" link that was entered in the previous phase). The Development Proposal tracker should also be updated to include the cross-project related fields and any project-level specs/blueprints information as it becomes available.
Conditions For Movement of Development Proposal
Development Proposal Idea -> Proposed Change/Patch: Anyone can submit a Development Proposal to this folder, this is the starting point for Development Proposals.
Review Proposed -> Merge Proposed: The Development Proposal must meet template standards (e.g. all mandatory sections completed) and the concept has been refined by the Product WG through the gerrit review process.
Merged Proposed -> Cross Project Spec Change/Patch: A Development Proposal owner must be identified at this point and they are responsible for creating the cross-project spec submission. The Development Proposal owner will also change the "cross project spec link:" to "ready to submit" in a single-line change to the proposed Development Proposal, this indicates to the Product WG that this Development Proposal is about to be submitted for review by the technical community/cross project team. An initial tracker for the Development Proposal must also be created by the Development Proposal owner so the OpenStack community can track the status of the Development Proposal moving forward.
