Difference between revisions of "StarlingX/Feature Development Process"

Revision as of 23:30, 13 September 2018

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

StarlingX Feature Handling Process

General

StarlingX is using the StoryBoard tool for tracking features and enhancements. Here is a link to our StoryBoard project group.
If you would like to propose a new Feature or Enhancement to StarlingX, please follow the process defined on this wiki page.
The StarlingX project does not follow the standard OpenStack project team guidelines for release and feature management, documented here. We have decided in the initial phase of the project to adopt a lighter process and a shorter release cycle.

Terminology

Bug fix - a change to the software to correct a defect.
Enhancement - a change to the software for internal reasons (e.g. refactoring to improve testability, python2->3, etc…)
Feature - a change to the software that is visible to end users

The defect handling process is defined at INSERT LINK HERE and is separate process from the Feature Planning process. For the purposes of this discussion we will treat Enhancements in the same way as Features and use the word Feature to refer to both.

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 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

@@ Line 13: / Line 13: @@
 * Enhancement - a change to the software for internal reasons (e.g. refactoring to improve testability, python2->3, etc…)
 * Feature - a change to the software that is visible to end users
+The defect handling process is defined at INSERT LINK HERE and is separate process from the Feature Planning process.
+For the purposes of this discussion we will treat Enhancements in the same way as Features and use the word Feature to refer to both.
 === StarlingX Feature Lifecycle / Process ===