Jump to: navigation, search

Difference between revisions of "StarlingX/Feature Development Process"

Line 5: Line 5:
  
 
== General ==
 
== General ==
* StarlingX is using story board for tracking features and enhancements:  
+
* StarlingX is using story board for tracking features and enhancements: https://storyboard.openstack.org/#!/project_group/86
 
* Generally, StarlingX follows the openstack project team guidelines for release and feature management, documented [https://docs.openstack.org/project-team-guide/release-management.html here].
 
* Generally, StarlingX follows the openstack project team guidelines for release and feature management, documented [https://docs.openstack.org/project-team-guide/release-management.html here].
  
 
== StarlingX Feature Lifecycle / Process ==
 
== StarlingX Feature Lifecycle / Process ==
 
=== Feature Proposal ===
 
=== Feature Proposal ===
* The majority of  
+
* Any contributor in the community can propose a feature for inclusion in StarlingX at any time.
 +
** However, the majority of features will be reviewed/accepted during a specific release planning phase per release.
 +
** If the contributor is targeting a particular release, they should align their proposal/spec review within the planning period
 +
* To start, the contributor can propose the feature by creating a Story in the [https://storyboard.openstack.org/#!/project_group/86 StarlingX StoryBoard]
 +
* The contributor can then reach out to the StarlingX TSC / TLs / mailing list to socialize the feature and get initial feedback
 +
* The contributor proceeds to create a feature spec and gerrit review, using the [StarlingX/FeatureSpecTemplate StarlingX Feature Spec Template]
 +
* The contributor creates a gerrit review for the feature spec. StarlingX feature specs are stored in gerrit at starlingx/stx-specs: ''<add link here>''
  
 
=== Feature Spec Review / Scheduling ===
 
=== Feature Spec Review / Scheduling ===
*  
+
* Feature Specs are reviewed by the StarlingX TSC / Technical Leads using gerrit
 +
* As already noted above, the majority of features will be reviewed during a specific release planning phase per release. However, smaller features/enhancements can be reviewed and scheduled outside of this time period.
 +
* Feature Acceptance Criteria
 +
** TBD
 +
* Once a feature is accepted based on the technical review:
 +
** A target StarlingX release is proposed for the feature. The feature story in Story Board will be tagged with the target release by the StarlingX Release Prime.
 +
** The feature is assigned to a sub-project or cross-project team for development.
 +
*** For large scope features/initiatives, a cross-project team may be put together from the interested community contributors
 +
** The feature resourcing is secured.
 +
*** It is often expected that the person/group who proposed the feature are willing to provide the resourcing to develop it.
  
 
=== Feature Development ===
 
=== Feature Development ===
* Once a feature is approved/scheduled for a release, the Team Lead
+
* The development team breaks down the feature into tasks and starts development/testing
 +
** Tasks are added under the feature story in Story Board.
 +
** Ideally, want to be able to have a hierarchy of stories ...especially for big features/initiatives
 +
* For large scope features, it is recommended to use a feature branch <ToDo: add some info on how to request/create a feature branch>
 +
* <ToDo: add more info on regular submissions, automated testing, etc>
  
 
=== Feature Verification ===
 
=== Feature Verification ===
 +
* TBD
  
 +
=== Related Topics ===
 +
* What's a feature and what's a small enhancement?
 +
* Are tools/build/infrastructure features which should follow the same process above? Ghada says yes :)
 +
* Need some guidelines for story board creation and triage
  
 
== StarlingX Story Board Queries ==
 
== StarlingX Story Board Queries ==
 
+
*
  
 
== References ==
 
== References ==
[[https://docs.openstack.org/project-team-guide/release-management.html Openstack Release Managementi]
+
* [https://docs.openstack.org/project-team-guide/release-management.html Openstack Release Management]
 +
* [StarlingX/Release_Plan|StarlingX Release Planning]

Revision as of 13:04, 12 September 2018

This is Work In Progress -- still needs review and agreement by the team

StarlingX Feature Handling Process

General

StarlingX Feature Lifecycle / Process

Feature Proposal

  • Any contributor in the community can propose a feature for inclusion in StarlingX at any time.
    • However, the majority of features will be reviewed/accepted during a specific release planning phase per release.
    • If the contributor is targeting a particular release, they should align their proposal/spec review within the planning period
  • To start, the contributor can propose the feature by creating a Story in the StarlingX StoryBoard
  • The contributor can then reach out to the StarlingX TSC / TLs / mailing list to socialize the feature and get initial feedback
  • The contributor proceeds to create a feature spec and gerrit review, using the [StarlingX/FeatureSpecTemplate StarlingX Feature Spec Template]
  • The contributor creates a gerrit review for the feature spec. StarlingX feature specs are stored in gerrit at starlingx/stx-specs: <add link here>

Feature Spec Review / Scheduling

  • Feature Specs are reviewed by the StarlingX TSC / Technical Leads using gerrit
  • As already noted above, the majority of features will be reviewed during a specific release planning phase per release. However, smaller features/enhancements can be reviewed and scheduled outside of this time period.
  • Feature Acceptance Criteria
    • TBD
  • Once a feature is accepted based on the technical review:
    • A target StarlingX release is proposed for the feature. The feature story in Story Board will be tagged with the target release by the StarlingX Release Prime.
    • The feature is assigned to a sub-project or cross-project team for development.
      • For large scope features/initiatives, a cross-project team may be put together from the interested community contributors
    • The feature resourcing is secured.
      • It is often expected that the person/group who proposed the feature are willing to provide the resourcing to develop it.

Feature Development

  • The development team breaks down the feature into tasks and starts development/testing
    • Tasks are added under the feature story in Story Board.
    • Ideally, want to be able to have a hierarchy of stories ...especially for big features/initiatives
  • For large scope features, it is recommended to use a feature branch <ToDo: add some info on how to request/create a feature branch>
  • <ToDo: add more info on regular submissions, automated testing, etc>

Feature Verification

  • TBD

Related Topics

  • What's a feature and what's a small enhancement?
  • Are tools/build/infrastructure features which should follow the same process above? Ghada says yes :)
  • Need some guidelines for story board creation and triage

StarlingX Story Board Queries

References