You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Note:  this is a working page for developing the new milestone exception request process.  It has not yet been reviewed or approved by the TSC.

Purpose

The purpose of the exception request process is to enable projects and requirements owners to make a request to the TSC for an exception in the following cases:

  1. A project has been determined as NOGO at a milestone checkpoint, but the PTL believes that the project can complete the requirement and catch up to the regular schedule. 
  2. A Use Case or Requirement has failed to receive TSC approval at one of the milestone checkpoints. However, the use case or requirement owner disputes the analysis.

In these cases, a small team of TSC members will review the request, discuss it with stakeholders, and make a recommendation to the TSC whether to approve the request.  The intent is for the analysis and the decision to be made by the TSC, rather than by an individual.

Process

  1. A project, Use Case, or Requirement is identified as NOGO for a release milestone. 
  2. If the the project PTL, or the requirement owner, dispute the assessment, then they may submit an exception request via the ONAP wiki.  Please complete all fields in as much detail as possible.
  3. Once the form has been completed and saved, notify the release manager and the TSC chair that an exception request has been submitted.
  4. The release manager will inform the review team, who will begin the review as soon as possible.
  5. Once the review team has completed their assessment and developed a recommendation, they will inform the release manager and the TSC chair of their decision.
  6. The TSC chair or the release manager will send mail to the TSC mailing list, informing the TSC of the decision.
  7. A discussion and vote will be scheduled for the next TSC meeting.

Exception Request Review Team

  • Team is composed of at least 5 community volunteers.
  • The review team serves for two releases.
  • There should be no more than one team member from any one company.
  • Team members should recuse themselves if they have direct involvement with the project or requirement in question.
  • No labels