ProductTeam/Development Proposals - Revision history

Au3678 at 20:30, 7 May 2017

2017-05-07T20:30:50Z

Au3678 at 20:30, 7 May 2017

2017-05-07T20:30:33Z

Gerald K: changing links to new repo

2017-04-25T14:28:43Z

changing links to new repo

ThierryCarrez: ThierryCarrez moved page ProductTeam/User Stories to ProductTeam/Development Proposals: As agreed by the ProductWG and requested by GeraldK

2017-04-12T08:41:31Z

ThierryCarrez moved page ProductTeam/User Stories to ProductTeam/Development Proposals: As agreed by the ProductWG and requested by GeraldK

Yih Leong Sun: /* Development Proposal Workflow */

2017-04-06T16:20:03Z

‎Development Proposal Workflow

Gerald K: Update from user story to Development Proposal

2017-04-03T21:34:02Z

Update from user story to Development Proposal

Gerald K: /* Sub-Pages for Active User Stories */ Action item to remove user story sub pages

2017-03-29T10:08:52Z

‎Sub-Pages for Active User Stories: Action item to remove user story sub pages

Kaizen: /* Gap and Overlap Analysis */

2016-06-13T21:35:27Z

‎Gap and Overlap Analysis

Kaizen: /* User Story Workflow */

2016-05-09T17:38:29Z

‎User Story Workflow

Adam Spiers: /* Sub-Pages for Active User Stories */ add HA VMs user story

2016-04-28T22:47:52Z

‎Sub-Pages for Active User Stories: add HA VMs user story

@@ Line 1: / Line 1: @@
 == 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 [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]. dd
+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/development-proposals/blob/master/doc/source/workflow/taxonomy.rst taxonomy] shows more details on the mapping on product WG mapping to agile terminology.

@@ Line 1: / Line 1: @@
 == 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 [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].
+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]. dd
 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.
@@ Line 12: / Line 12: @@
 <br><br>
 ==== 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.
 <br><br>

@@ Line 1: / Line 1: @@
 == 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 [https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst standard template] which is located on the [https://github.com/openstack/openstack-user-stories 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/openstack-user-stories/ specs page].
+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/openstack-user-stories/blob/master/doc/source/workflow/taxonomy.rst taxonomy] shows more details on the mapping on product WG mapping to agile terminology.
+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 ===
@@ Line 9: / Line 9: @@
 </center>
-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/openstack-user-stories/tree/master/user-stories/proposed proposed folder] in the repository.
+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>
 ==== Gap and Overlap Analysis ====
@@ Line 21: / Line 21: @@
 ==== 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/openstack-user-stories/blob/master/doc/source/tracker_overview.rst Development Proposal tracker] using the [https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json Development Proposal tracker template] with only the Development Proposal related fields completed.<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>

@@ Line 5: / Line 5: @@
 === Development Proposal Workflow ===
-<center>[[File:Userstoryflow.png|center|Development Proposal Workflow]]
+<center>
-figure 1.1</center>
+[[File:Development Proposal Workflow.png|center|Development Proposal Workflow]] Figure 1.1 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 [https://github.com/openstack/openstack-user-stories/tree/master/user-stories/proposed proposed folder] in the repository.

@@ Line 1: / Line 1: @@
-== User Stories ==
+== Development Proposals ==
-The Product Working Group discusses proposals, both, internally and externally using user stories.  The user stories are created using a [https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst standard template] which is located on the [https://github.com/openstack/openstack-user-stories Product WG Repository].  The process for proposing and, eventually, implementing user stories is depicted in figure 1.1.  The primary source for information on Product WG user stories is our [http://specs.openstack.org/openstack/openstack-user-stories/ specs page], the user story sub-pages listed here are meant to provide additional information about the team that is working on the user story (members, meeting times, etc.) and supporting artifacts for the user story that do not fit the defined template.
+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/openstack-user-stories/blob/master/user-story-template.rst standard template] which is located on the [https://github.com/openstack/openstack-user-stories 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/openstack-user-stories/ specs page].
 This [https://github.com/openstack/openstack-user-stories/blob/master/doc/source/workflow/taxonomy.rst taxonomy] shows more details on the mapping on product WG mapping to agile terminology.
-=== User Story Workflow ===
+=== Development Proposal Workflow ===
-<center>[[File:Userstoryflow.png|center|User Story Workflow]]
+<center>[[File:Userstoryflow.png|center|Development Proposal Workflow]]
 figure 1.1</center>
-The workflow covers the proposal, refinement, acceptance, and implementation of the user story.  Anyone is allowed to post a user story to the [https://github.com/openstack/openstack-user-stories/tree/master/user-stories/proposed proposed folder] in the repository.
+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/openstack-user-stories/tree/master/user-stories/proposed proposed folder] in the repository.
 <br><br>
 ==== Gap and Overlap Analysis ====
-The team must conduct a technical gaps and overlaps analysis once a user story concept has been validated and any overlaps/conflicts with other proposed user stories have been remediated.  The user story 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 user story.  This meeting will be used by the team to validate the approach/concept, determine whether any proposed user stories have to be deferred based on prior work inside the project(s), and the best way to proceed based on the outcome.
+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.
 <br><br>
 ==== 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 user story priorities or user story tracker).    The goal of the implementation plan is to agree upon the next steps for a given user story 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 user story owner, user story technical SME(s), and cross-project spec liaisons for the relevant projects).
+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 User Stories====
+==== Possible Statuses for Development Proposals ====
-<b>Proposed:</b> User stories are first submitted as a patch to this location in the repository.  In this phase, the user story 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 user story 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 user story has reached a point where the concept is considered validated by the team.<br><br>
+<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 user story is ready for community discussion, the user story owner will submit a change to the [https://github.com/openstack/openstack-specs cross-project specs repository] and update the user story in the "proposed" folder with a link to the cross-project spec review.  The user story owner will also create an initial [https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst user story tracker] using the [https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json user story tracker template] with only the user story related fields completed.<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/openstack-user-stories/blob/master/doc/source/tracker_overview.rst Development Proposal tracker] using the [https://github.com/openstack/openstack-user-stories/blob/master/user-story-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 user story 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 user story owner, at this phase, will update the user story 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 user story tracker should also be updated to include the cross-project related fields and any project-level specs/blueprints information as it becomes available.<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>
-==== Conditions For Movement of User Story ====
+==== Conditions For Movement of Development Proposal ====
-<b>User Story Idea -> Proposed Change/Patch:</b> Anyone can submit a user story to this folder, this is the starting point for user stories<br><br>
+<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 user story 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>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 user story owner must be identified at this point and they are responsible for creating the cross-project spec submission.  The user story owner will also change the "cross project spec link:" to "ready to submit" in a single-line change to the proposed user story, this indicates to the Product WG that this user story is about to be submitted for review by the technical community/cross project team.  An initial tracker for the user story must also be created by the user story owner so the OpenStack community can track the status of the user story moving forward.<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>

← Older revision	Revision as of 08:41, 12 April 2017
(No difference)

← Older revision		Revision as of 10:08, 29 March 2017
Line 28:		Line 28:
	<b>Review Proposed -> Merge Proposed:</b> The user story 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>Review Proposed -> Merge Proposed:</b> The user story 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 user story owner must be identified at this point and they are responsible for creating the cross-project spec submission. The user story owner will also change the "cross project spec link:" to "ready to submit" in a single-line change to the proposed user story, this indicates to the Product WG that this user story is about to be submitted for review by the technical community/cross project team. An initial tracker for the user story must also be created by the user story owner so the OpenStack community can track the status of the user story moving forward.<br><br>		<b>Merged Proposed -> Cross Project Spec Change/Patch:</b> A user story owner must be identified at this point and they are responsible for creating the cross-project spec submission. The user story owner will also change the "cross project spec link:" to "ready to submit" in a single-line change to the proposed user story, this indicates to the Product WG that this user story is about to be submitted for review by the technical community/cross project team. An initial tracker for the user story must also be created by the user story owner so the OpenStack community can track the status of the user story moving forward.<br><br>
−
−	~~=== Sub-Pages for Active User Stories ===~~
−	~~==== [[ProductTeam/User Stories/Capacity Management\|Quotas, Usage Plans, and Capacity Management]] ====~~
−	~~==== [[ProductTeam/User Stories/Lifecycle Management\|Lifecycle Management for VMs]] ====~~
−	~~==== [[ProductTeam/User Stories/Onboarding Legacy Apps\|Onboarding Legacy Apps into OpenStack]] ====~~
−	~~==== [[ProductTeam/User Stories/Rolling Upgrades\|Rolling Upgrades]] ====~~
−	~~==== [[ProductTeam/User Stories/HA VMs\|Highly Available VMs]] ====~~

← Older revision		Revision as of 22:47, 28 April 2016
Line 26:		Line 26:
	==== [[ProductTeam/User Stories/Onboarding Legacy Apps\|Onboarding Legacy Apps into OpenStack]] ====		==== [[ProductTeam/User Stories/Onboarding Legacy Apps\|Onboarding Legacy Apps into OpenStack]] ====
	==== [[ProductTeam/User Stories/Rolling Upgrades\|Rolling Upgrades]] ====		==== [[ProductTeam/User Stories/Rolling Upgrades\|Rolling Upgrades]] ====
		+	==== [[ProductTeam/User Stories/HA VMs\|Highly Available VMs]] ====