Jump to: navigation, search

Difference between revisions of "StarlingX/Feature Development Process"

(Terminology)
(Introduction)
 
(48 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== StarlingX Feature Handling Process ==
+
=== Introduction ===
 +
'''This page is no longer valid.'''  The StarlingX development process documentation has moved to [https://docs.starlingx.io/contributor/development_process.html docs.starlingx.io].  This page is preserved for archival purposes.
  
This page is under construction.
+
The StarlingX Feature handling process is designed to enable the project team to manage their work following the [https://governance.openstack.org/tc/reference/opens.html Four Opens].  StarlingX is using the StoryBoard tool for tracking features and enhancements.  
  
=== General ===
+
The StarlingX project is similar to but does ''not'' follow the standard OpenStack process for release and feature management, documented [https://docs.openstack.org/project-team-guide/release-management.html here].  We have chosen in the initial phase of the project to adopt a shorter release cycle and to not couple Feature development to overall project milestones.
* StarlingX is using the StoryBoard tool for tracking features and enhancements.  Here is [https://storyboard.openstack.org/#!/project_group/86 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 [https://docs.openstack.org/project-team-guide/release-management.html here].  We have decided in the initial phase of the project to adopt a lighter process and a shorter release cycle.
 
  
=== Terminology ===
+
If you would like to propose a new Feature or Enhancement to StarlingX, please follow the Easy Mode steps described below. If you are a StarlingX Contributor or would like to become one and implement Features, there is also an Easy Mode for that, but you should also review and understand the full Feature process as defined below.
* 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.
+
=== Easy Mode ===
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.
+
==== How to submit a new Feature ====
 +
To submit a new Feature for StarlingX, all you need to do is:
 +
* Point your browser at [https://storyboard.openstack.org/#!/project_group/86 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. 
 +
* 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.
  
Not all features are created equalSome are simple, small, contained within one project, and easy to implementOthers may span multiple StarlingX sub-projects, have a high degree of complexity or require a significant amount of new/changed codeWe will call the former Simple Features and the later Complex Features.
+
==== How to work on a Feature ====
 +
To work on a Feature in StarlingX, all you need to do is:
 +
* Find a Feature that you'd like to work on that is in the Approved state (tagged stx.approved)That means the TSC and the team's Project Lead(s) have reviewed and approved the feature for development[https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=86&tags=stx.approved Here is a sample query].
 +
* Review the StoryBoard description and the specification for the Feature.
 +
* Reach out to the project team on the mailing list and/or IRC and join in!
 +
* If there is no one actively working on the Feature, please change the tags in the Story for the FeatureRemove the "stx.approved" tag and replace it with "stx.inprogress".  Please add your name to any Tasks in the Story you are working on.
 +
* Follow the rest of the process as described below.
  
=== StarlingX Feature Life cycle / Process ===
+
=== The Feature Development Process ===
 +
Here is the full description of the StarlingX process.
  
==== Feature Life cycle ====
+
==== Summary ====
Features follow a common life cycle.  We will track Features through each step.
+
New Features ideas are reviewed by the project's TSC, and assigned to sub-project team(s) for implementation.  All of the work is tracked in StoryBoard Stories, which are tagged to show a more detailed state than what the tool can currently provide.  Story states follow a Feature life-cycle from the initial review through the completed implementation.  All work on a Feature is open, tracked in databases and available for anyone on the project to review, provide feedback on, contribute to and learn about.
 +
 
 +
==== 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 StarlingX project has a separate process for handling defects, which is defined by the [[StarlingX/Defect Handling Process|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.  In general this is a subjective call by the Project Lead(s) and only impacts the process when determining how much of a specification is needed for a Feature.
 +
 
 +
==== StarlingX Feature Life cycle / Process ====
 +
 
 +
===== Feature Life cycle =====
 +
Features follow a common life cycle.  We track Features through each step using StoryBoard tags.
 
Our proposed Feature life cycle steps are:
 
Our proposed Feature life cycle steps are:
* New - this is a new idea from a user, a developer or other project stakeholder
+
* '''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.   
+
* '''Analysis''' - the feature is being reviewed, scoped and estimated by the project team.   
* Approved- The feature has been reviewed and approved for implementation
+
* '''Approved'''- The feature has been reviewed and approved for implementation
* In progress -The feature is being worked on
+
* '''In progress''' -The feature is actively being worked on
* Complete - The feature has been fully implemented and tested
+
* '''Complete''' - The feature has been fully implemented and tested
* Released - The completed feature has been formally released  
+
* '''Released''' - The completed feature has been formally released  
* Rejected - The project team has decided to not implement the feature
+
* '''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
+
* '''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 follow the Easy Mode steps defined above.
 +
 
 +
The StarlingX Technical Steering Committee has the responsibility to review all New Features 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 Analysis, Rejected or Deferred states, using the stx.analysis, stx.deferred or stx.rejected tags.
 +
 
 +
====== Analysis State ======
 +
Features in the Analysis 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 affected 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 for Simple Features, or the creation of a formal spec document for Complex Features.  In the later case, please add a link to the spec file into the StoryBoard Story for the feature.  See below for the spec creation process.
 +
 
 +
One of the first steps in the Analysis process is for the Feature to be posted to the project's mailing list, either by the TSC or the Project Lead.  Email review by the broader community is critical to the Feature development process.
 +
 
 +
Project leads for a Feature can break the Feature down into multiple StoryBoard stories at their discretion.  Each Story should be treated as a separate Feature and managed through this process.  Note that we do not currently have a way in the tool to build hierarchies of Stories or to indicate dependencies between Stories.  Project leads and/or the project team can define additional Tasks in StoryBoard for Feature Stories as needed.
 +
 
 +
Once the Project Lead(s) have completed their analysis, updated the Story(s), approved the spec and assigned the Feature to a target release (by tagging the Story), the Feature is moved to the Approved state with the agreement of all impacted Project Leads by replacing the "stx.analysis" tag with the "stx.approved" tag.  If the Project Leads do not agree, they should seek consensus or raise the issue with the TSC for resolution.
  
===== New State =====
+
====== Approved State ======
Any member of the StarlingX community can propose a new feature at any timeTo 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.
+
Features in the Approved state are ready for work to beginOnce the project team(s) start work, they should update the Story's tag by removing stx.approved and adding stx.inprogress.
  
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 progress State ======
 +
Please follow the Easy Mode instructions above for how to begin work on an Approved Feature.
  
===== In Review State =====
+
====== Complete ======
Features in the In Review state are assigned to one (or more) Project Leads for deeper analysis and scopingFeatures 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.
+
Features are moved to the Complete state when all work required to implement the Feature is doneFor the purposes of this process, the work is done when
 +
# All of the code changes for the Feature have been merged to the git repos
 +
# Any documentation effected by the code changes has been updated on the wiki and/or in stx-docs.
 +
# Any feature branch created is deleted
 +
# The feature has been tested to the satisfaction of the sub-project Project Lead(s) and Core Reviewers.
  
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.
+
In the near term testing is likely to be basic functional testing of the new code.  Long term we would like to see automated functional and unit tests checked in together with the new Feature code.
  
==== Feature Proposal ====
+
Features that are Complete should have the "stx.inprogress" tag removed and have the "stx.complete" added.
* 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 ====
+
====== Released ======
* Feature Specs are reviewed by the StarlingX TSC / Technical Leads using gerrit
+
Features are moved to the Released state by the Release sub-project team once they are included in a formal project Release. This is done by removing the "stx-complete" tag and adding the "stx-released" tag.
* 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 ====
+
====== Rejected ======
* The development team breaks down the feature into tasks and starts development/testing
+
Features are moved to the Rejected state by the TSC if they determine that the Feature should not be implemented.  The TSC should provide guidance and feedback to the Story's submitter as to why the feature was rejected.  To move the story to the Rejected state the TSC should replace the "stx.new" tag with "stx.rejected" and move the Story to Invalid.
** 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 ====
+
====== Deferred ======
* TBD
+
Features are moved to the Rejected state by the TSC if they determine that the Feature should be implemented but not in the foreseeable future.  The TSC should provide guidance and feedback to the Story's submitter as to why the feature was deferred.  To move the story to the Deferred state the TSC should replace the "stx.new" tag with "stx.deferred"
  
==== Related Topics ====
+
==== Specification Process ====
* What's a feature and what's a small enhancement?
+
* Each Feature shall have a specification (spec), written by the Project Lead(s) or their delegates
* Are tools/build/infrastructure features which should follow the same process above? Ghada says yes :)
+
* Specs shall be regularly posted to the email list for broader review during spec development
* Need some guidelines for story board creation and triage
+
* Specs for Simple Features can be a paragraph in the StoryBoard Description field at the discretion of the Project Lead(s).  Which should also cut-n-pasted to the email list for review.
 +
* Specs for Complex Features shall be documents that are checked into the repo stx-specs/approved/<category>-<storyboard#>-<feature name>.txt, using the [[StarlingX/FeatureSpecTemplate| StarlingX Feature Spec Template]]
 +
* Once the spec is first uploaded to gerrit, the spec review can be conducted in gerrit.  As a courtesy to the team, spec authors are encouraged to send RFC emails to the project mailing list seeking additional feedback for the gerrit reviews.
 +
* Specs can be merged into the repo after review and approval by the TSC.  Spec approval requires a simple majority of the current TSC membership.  If after two days of reaching majority if no negative votes are cast the review may be merged.
  
=== StarlingX Story Board Queries ===
+
==== General guidelines for Feature development ====
*  
+
* We are always interested in new ideas for Features. 
 +
* For Features with a very large implementation effort, a feature branch should be created for the work to minimize the impact on the git mainline.
 +
* If work on a Feature spans multiple release cycles, work on that feature must be in a feature branch, or implemented in such a way to avoid de-stabilizing the mainline (e.g. feature flags).
 +
* The Release team will work with Project Leads across the project to monitor and adjust release dates if/when they need to change during Feature development.
 +
* We hope that anyone proposing a new Feature are also willing to contribute to the Feature's development.  This can include anything from just answering questions about how the Feature should behave, to actively contributing code to the Feature, and helping test the completed Feature.
  
=== References ===
+
=== Open Issues ===
* [https://docs.openstack.org/project-team-guide/release-management.html Openstack Release Management]
+
* We need to define the Spec Template.
* [[StarlingX/Release_Plan|StarlingX Release Planning Process]]
+
* Do we add additional milestones?  We have been doing monthly builds but these are time based snapshots with no context attached to them.
 +
* Setting priorities - coupled with resource allocation.  Small scale features can be prioritized by the Project & Team lead.  Larger scale features should be prioritized by the TSC.  Priorities should reflect resource assignments - something can’t be important but not assign to devs…. Impact to the existing code base should be considered
 +
* What does it mean for a Feature to be Done?  Like Agile Acceptance Criteria, do we want to specify those in the spec itself?  Hold PLs and TL’s accountable?
 +
* AR Team - how can we arrange for open testing of StarlingX?  Is this just 3rd party CI???

Latest revision as of 18:03, 14 February 2020

Introduction

This page is no longer valid. The StarlingX development process documentation has moved to docs.starlingx.io. This page is preserved for archival purposes.

The StarlingX Feature handling process is designed to enable the project team to manage their work following the Four Opens. StarlingX is using the StoryBoard tool for tracking features and enhancements.

The StarlingX project is similar to but does not follow the standard OpenStack process for release and feature management, documented here. We have chosen in the initial phase of the project to adopt a shorter release cycle and to not couple Feature development to overall project milestones.

If you would like to propose a new Feature or Enhancement to StarlingX, please follow the Easy Mode steps described below. If you are a StarlingX Contributor or would like to become one and implement Features, there is also an Easy Mode for that, but you should also review and understand the full Feature process as defined below.

Easy Mode

How to submit a new Feature

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

How to work on a Feature

To work on a Feature in StarlingX, all you need to do is:

  • Find a Feature that you'd like to work on that is in the Approved state (tagged stx.approved). That means the TSC and the team's Project Lead(s) have reviewed and approved the feature for development. Here is a sample query.
  • Review the StoryBoard description and the specification for the Feature.
  • Reach out to the project team on the mailing list and/or IRC and join in!
  • If there is no one actively working on the Feature, please change the tags in the Story for the Feature. Remove the "stx.approved" tag and replace it with "stx.inprogress". Please add your name to any Tasks in the Story you are working on.
  • Follow the rest of the process as described below.

The Feature Development Process

Here is the full description of the StarlingX process.

Summary

New Features ideas are reviewed by the project's TSC, and assigned to sub-project team(s) for implementation. All of the work is tracked in StoryBoard Stories, which are tagged to show a more detailed state than what the tool can currently provide. Story states follow a Feature life-cycle from the initial review through the completed implementation. All work on a Feature is open, tracked in databases and available for anyone on the project to review, provide feedback on, contribute to and learn about.

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 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. In general this is a subjective call by the Project Lead(s) and only impacts the process when determining how much of a specification is needed for a Feature.

StarlingX Feature Life cycle / Process

Feature Life cycle

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

  • New - this is a new idea from a user, a developer or other project stakeholder
  • Analysis - the feature is being reviewed, scoped and estimated by the project team.
  • Approved- The feature has been reviewed and approved for implementation
  • In progress -The feature is actively 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 follow the Easy Mode steps defined above.

The StarlingX Technical Steering Committee has the responsibility to review all New Features 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 Analysis, Rejected or Deferred states, using the stx.analysis, stx.deferred or stx.rejected tags.

Analysis State

Features in the Analysis 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 affected 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 for Simple Features, or the creation of a formal spec document for Complex Features. In the later case, please add a link to the spec file into the StoryBoard Story for the feature. See below for the spec creation process.

One of the first steps in the Analysis process is for the Feature to be posted to the project's mailing list, either by the TSC or the Project Lead. Email review by the broader community is critical to the Feature development process.

Project leads for a Feature can break the Feature down into multiple StoryBoard stories at their discretion. Each Story should be treated as a separate Feature and managed through this process. Note that we do not currently have a way in the tool to build hierarchies of Stories or to indicate dependencies between Stories. Project leads and/or the project team can define additional Tasks in StoryBoard for Feature Stories as needed.

Once the Project Lead(s) have completed their analysis, updated the Story(s), approved the spec and assigned the Feature to a target release (by tagging the Story), the Feature is moved to the Approved state with the agreement of all impacted Project Leads by replacing the "stx.analysis" tag with the "stx.approved" tag. If the Project Leads do not agree, they should seek consensus or raise the issue with the TSC for resolution.

Approved State

Features in the Approved state are ready for work to begin. Once the project team(s) start work, they should update the Story's tag by removing stx.approved and adding stx.inprogress.

In progress State

Please follow the Easy Mode instructions above for how to begin work on an Approved Feature.

Complete

Features are moved to the Complete state when all work required to implement the Feature is done. For the purposes of this process, the work is done when

  1. All of the code changes for the Feature have been merged to the git repos
  2. Any documentation effected by the code changes has been updated on the wiki and/or in stx-docs.
  3. Any feature branch created is deleted
  4. The feature has been tested to the satisfaction of the sub-project Project Lead(s) and Core Reviewers.

In the near term testing is likely to be basic functional testing of the new code. Long term we would like to see automated functional and unit tests checked in together with the new Feature code.

Features that are Complete should have the "stx.inprogress" tag removed and have the "stx.complete" added.

Released

Features are moved to the Released state by the Release sub-project team once they are included in a formal project Release. This is done by removing the "stx-complete" tag and adding the "stx-released" tag.

Rejected

Features are moved to the Rejected state by the TSC if they determine that the Feature should not be implemented. The TSC should provide guidance and feedback to the Story's submitter as to why the feature was rejected. To move the story to the Rejected state the TSC should replace the "stx.new" tag with "stx.rejected" and move the Story to Invalid.

Deferred

Features are moved to the Rejected state by the TSC if they determine that the Feature should be implemented but not in the foreseeable future. The TSC should provide guidance and feedback to the Story's submitter as to why the feature was deferred. To move the story to the Deferred state the TSC should replace the "stx.new" tag with "stx.deferred"

Specification Process

  • Each Feature shall have a specification (spec), written by the Project Lead(s) or their delegates
  • Specs shall be regularly posted to the email list for broader review during spec development
  • Specs for Simple Features can be a paragraph in the StoryBoard Description field at the discretion of the Project Lead(s). Which should also cut-n-pasted to the email list for review.
  • Specs for Complex Features shall be documents that are checked into the repo stx-specs/approved/<category>-<storyboard#>-<feature name>.txt, using the StarlingX Feature Spec Template
  • Once the spec is first uploaded to gerrit, the spec review can be conducted in gerrit. As a courtesy to the team, spec authors are encouraged to send RFC emails to the project mailing list seeking additional feedback for the gerrit reviews.
  • Specs can be merged into the repo after review and approval by the TSC. Spec approval requires a simple majority of the current TSC membership. If after two days of reaching majority if no negative votes are cast the review may be merged.

General guidelines for Feature development

  • We are always interested in new ideas for Features.
  • For Features with a very large implementation effort, a feature branch should be created for the work to minimize the impact on the git mainline.
  • If work on a Feature spans multiple release cycles, work on that feature must be in a feature branch, or implemented in such a way to avoid de-stabilizing the mainline (e.g. feature flags).
  • The Release team will work with Project Leads across the project to monitor and adjust release dates if/when they need to change during Feature development.
  • We hope that anyone proposing a new Feature are also willing to contribute to the Feature's development. This can include anything from just answering questions about how the Feature should behave, to actively contributing code to the Feature, and helping test the completed Feature.

Open Issues

  • We need to define the Spec Template.
  • Do we add additional milestones? We have been doing monthly builds but these are time based snapshots with no context attached to them.
  • Setting priorities - coupled with resource allocation. Small scale features can be prioritized by the Project & Team lead. Larger scale features should be prioritized by the TSC. Priorities should reflect resource assignments - something can’t be important but not assign to devs…. Impact to the existing code base should be considered
  • What does it mean for a Feature to be Done? Like Agile Acceptance Criteria, do we want to specify those in the spec itself? Hold PLs and TL’s accountable?
  • AR Team - how can we arrange for open testing of StarlingX? Is this just 3rd party CI???