Jump to: navigation, search

StarlingX/Feature Development Process

< StarlingX
Revision as of 16:34, 14 September 2018 by Bruce.e.jones (talk | contribs) (Terminology)

StarlingX Feature Handling Process

This page is under construction.


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

Easy Mode

If you would like to submit a new Feature for StarlingX, all you need to do is:

  • Point your browser at the StarlingX StoryBoard project group.
  • Click on the "Create new" button on the top of the page and select "Story" from the pull down menu.
  • A dialog box will appear
  • In the "Title" field in the dialog box, enter in a name for the Feature or a one sentence description. For bonus points, put the "[Feature]" prefix as the first part of the Title.
  • In the "Description" field of the dialog box, enter in a description of what you want the Feature to do and why you want it. For additional bonus points, use the StarlingX Feature Spec Template
  • In the "Project" field in the dialog box, enter in the name of the StarlingX sub-project repository that would implement your feature. These names all start with "stx-" which you can type to have a drop down list shown. If you don't know which repo to select, you can use "stx-integ".
  • Hit the "Save Changes" and you are done!
  • For additional bonus points, once your Story is created, please add the "stx.new" and "stx.feature" tags to the Story you just created.


  • 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 StarlingX project has a separate process for handling defects, which is defined by the StarlingX Defect Handling 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. What that means is that we'd like every code change that isn't a bug fix to use this process.

Not all features are created equal. Some are simple, small, contained within one project, and easy to implement. Others may span multiple StarlingX sub-projects, have a high degree of complexity or require a significant amount of new/changed code. We will call the former Simple Features and the later Complex Features.

StarlingX Feature Life cycle / Process

Feature Life cycle

Features follow a common life cycle. We will track Features through each step. Our proposed Feature life cycle steps are:

  • New - this is a new idea from a user, a developer or other project stakeholder
  • In review - New features need to be reviewed, scoped and estimated by the project team.
  • Approved- The feature has been reviewed and approved for implementation
  • In progress -The feature is being worked on
  • Complete - The feature has been fully implemented and tested
  • Released - The completed feature has been formally released
  • Rejected - The project team has decided to not implement the feature
  • Deferred - The project team has decided to implement the feature at some later point
New State

Any member of the StarlingX community can propose a new feature at any time. To do so, please create a new StoryBoard story, with the [Feature] prefix in the title, and tag the newly created Story with the stx.new and stx.feature tags.

The StarlingX Technical Steering Committee has the responsibility to review all New Features. They will review the proposed Feature for technical merit and alignment with the project's overall architecture. This review process can be iterative with the TSC providing feedback on the Feature or requesting additional information. Once the initial TSC review is complete, the TSC can move the Feature to the In Review, Rejected or Deferred states, using the stx.review, stx.deferred or stx.rejected tags. If a Feature is Rejected, the TSC should provide guidance and feedback to the submitter as to why that action was taken.

In Review State

Features in the In Review state are assigned to one (or more) Project Leads for deeper analysis and scoping. Features that span more than one StarlingX sub-project should be assigned to all the Project Leads of the effected projects. The Project Leads (and / or their delegates) then work together to architect and design the feature. This will result in the creation of a specification, which can either be just adding additional detail to the StoryBoard entry, or the creation of a formal spec document. See below for the spec creation process.

Once the Project Lead(s) have completed their analysis and spec, the Feature is moved to the Approved state with the agreement of all impacted Project Leads.

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

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