Entrance Criteria

When a Feature Candidate has been approved by WG or TSC vote in the Stage One: Candidate process, the Chair of that group shall have done the following:

  • Entered the Feature submission into the relevant Feature backlog(s)
  • Updated the Feature Design document’s “current status” to Feature Design
  • Notified the TSC about the new Feature approval both in the next TSC meeting and on the TSC mailing list

Cross-cutting Candidates

Feature Candidates whose scope covers more than one WG shall have an initial decomposition or work breakdown effort to create separate Epic entries in each WG’s backlog.  This effort shall fall under the responsibility of the TSC.

Work Breakdown (high-level design)

The WG Chair or designee shall lead the work breakdown within their WG according to their standard practices.  This shall include the creation of issues, prioritization of the tasks, and assigning resources.  The breadth of issues created shall cover not only the software coding effort, but also creation of tests, the QA process itself, and documentation creation/updates/linking.  To assist in the effort, the author(s) shall be invited to attend the WG meetings in order to answer any questions about the User Outcomes and potentially identify additional resources, if required, to accelerate Feature delivery.

Author and Sponsor Availability

The author(s) and Sponsors may need to be consulted periodically throughout Stage Two and are advised to make themselves available upon request.

Code release frequency

Individual atomic functionality may be committed and merged, thus made public, as it is completed.  This functionality, or sub-feature, shall be activated through feature flags, but shall be deactivated by default until the User Outcome is completed.

Feature promotion criteria

Once all User Outcomes are met, completed, and made public, the Feature’s status shall be deemed Supported, and the Feature Design will be promoted to Feature Support.

NOTE: The last pull request (PR) for the Feature before promotion should be changing the overarching feature flag to default "on". 


  • No labels

2 Comments

  1. David Booz

    1. It is possible that a new aspect of scope will be discovered here, we need a way to represent a flow back to the scope process in stage one.
    2. Please add a sentence or 2 to the work breakdown section to remind folks that creating automated tests and doc is part of the work breakdown, and therefore completion of these is also required to get to feature promotion.
    3. An additional feature completion criteria is one last PR to change the default for this feature's flags to "on"?

  2. Joe Pearson

    David Booz

    1. Yes.  There is a note in Stage One specifically about changes to scope when identified during the initial candidate submission.  However, we could definitely see scope change during development.  The trick is to balance this document giving proper guidance against being overly prescriptive.  At some point, we have to rely on human judgment to flesh out the details for each specific case.  For example, IMO we shouldn't have to spell out every conceivable situation and possible remedy.  New aspects could lead us to re-assign to a new WG, halt work and request new resources, request the author to re-write the feature submission entirely, or other solutions.  I'd hate to have to go down that rabbit-hole.
    2. Done.  Look good?
    3. Good point.  Added.