Page tree
Skip to end of metadata
Go to start of metadata

OPNFV will use an exception process to manage projects that do not meet key release milestones.  The release manager will determine which milestones are subject to the exception process.  For example:

  • MS2:  Test case documentation (i.e. test case database)
  • MS3:  Installer / OpenStack integration
  • MS5:  Scenario integration and feature freeze
  • MS6:  Test case implementation
  • MS10:  Documentation completed


  1. If a project is unable to meet the requirements of a milestone by the scheduled date, then they will have a 1-week grace period to recover.  
  2. If the requirement still has not been met by the end of the grace period, then, at the release manager's discretion, the project must either withdraw from the release, or request a milestone exception by completing the exception request form, then notifying the release manager by email, who will schedule the review.  
  3. The exception request will be reviewed by a volunteer team, who will make sure that the exception is clear and comprehensive. 
  4. The exception request will be evaluated for its impact on the entire schedule, including the likelihood of missing other milestones.  The intent is to capture the entire impact and avoid having an exception request for every milestone missed.
  5. The exception will be presented to the TSC, who will discuss and vote on the request.
  6. If the exception is approved:
    1. The milestone date will be rescheduled for the project, OR
    2. The milestone will be exempted, entirely
    3. If the exception is accepted, but the plan for recovery fails, then the project must withdraw from the release.
  7. If the exception is denied, then the project must withdraw from the release.

Evaluation Criteria 

This criteria will be used to evaluate exception requests prior to being submitted to the TSC for approval (see step #2 under "Process" above).

  1. The exception request is complete.
  2. The recovery plan is realistic, 
  3. The recovery plan includes detailed steps with a schedule so that the progress can be monitored.
  • No labels


  1. David McBride For option 1, is it intended to be discussed and voted in the TSC meeting or in gerrit and mailing list? The latter one could be done asynchronously. This could be more flexible and transparent for a geography distributed community.  For disputed tickets, we may take them to the meeting for a high efficient decision making process. My two cents.

  2. I think anything less than an opportunity for the full TSC to hear and weigh in on exception requests may be less than ideal. I do see however that many exception requests might bog down the TSC, although this may largely be due to a lack of clear and consistent format/argument for exception requests. So, one hybrid option is for a volunteer Exception Committee to form that would develop criteria for exception requests, then review & give feedback to exception requests such that they are clear and consistent in committee before passing to TSC for review and vote- much like the Project Proposal process. It may turn out that some requesters decide they cannot pass muster, and this process filters out requests which are not likely to pass TSC. In either case, this process should avoid wasting time on poorly formed/insufficient info debate in TSC, making review more efficient. 

    In regards to process, I certainly see the case where an exception request is merely for adding an individual scenario to a project. e.g. Project X is ready for MS5 for Fuel-based scenarios , but late on Apex-based scenarios due to exceptions still bein cleared up. The current language in Process does not accommodate the options where only certain scenario options are not ready, and so we could add to the language such that the Project/Project Scenario raises an exception request and has to withdraw the Project/Project Scenario is the exception is not granted.

    Food for Thought... 

  3. I agree with Bob. The decision shall be taken by the TSC, but the exemption request shall only be presented to the TSC after it has been ensured by means of a review that the request is well formulated and a reasonable recovery plan exists. In order to avoid that this review becomes a bottleneck or a place of dispute, the criteria for an exemption must be clearly defined.

    Letting an invidiual person take the exemption decision is not transparent enough in my opinion. Moreover, establishing and maintaining Exception Committeea which meets certain transparency requirements (i.e., a good mix of project and company representatives) seems to be be overhead in itself.

  4. On the "other considerations" I would answer "NO" to limit the number of exceptions for one project as it is very likely that if a project is lacking behind a couple of weeks, this delay may be pulled along the parts of release cycle, thereby requiring exceptions for multiple milestones.

    In addition, if a MS exception is granted, it should be able that this is already covering MS exceptions for few adjacent milestones as the recovery plan might require a delay in more than 1 MS. IMHO, in such case, we should not be burdened to discuss multiple times about exceptions for one project.

  5. I agree with others above, granting an exception is better to do in TSC, but we must make sure we can be fast enough. No long decision making is possible, especially when the exception request is issued one week after a milestone has been missed.

    Some additional remarks:

    1. In the wording we should make clear that exception requests should be sent before a project misses a milestone, not encourage projects to wait until one week after missing a milestone.
    2. We should consider dependencies between projects more clearly. Most projects when missing a milestone will affect other projects in their ability to meet future milestones. Therefore the exception request always should contain a list of affected projects. In many cases it will not be all projects having a dependency, since part of the functionality of a project could be available in time, so only a subset of the depending projects will be affected of the slip.
    3. The plan for recovery should clearly explain the measures that are taken to reduce the effect on other projects in addition to the own project's milestones.
    1. Ok - I updated the document per your suggestions.

  6. I wonder if it is useful to ask about the level of confidence. Perhaps it would be better to ask for risks related to the new schedule?

    1. Ok - I updated bullet #9.

  7. I agree with others above. I think we should discuss and document somewhere the criteria to approve en exception request. The TSC will then only evaluate if those criteria are met. That would speed up the vote and increase transparency.

    1. That makes sense.  Could you suggest some criteria to get us started?

      1. Added some points, hope they make sense.

        1. Thanks, Rossella.  Just to be clear, this is criteria that we would use in preparation for presenting the request to the TSC, and NOT the criteria that the TSC would use.  So, I disagree with point #3, "The risks associated with the recovery plan are low".  That is something that the TSC should decide.

        2. ... also, I think that bullet #2 "... detailed steps possibly with due date..." is already covered by  bullet #9 in the format:  "Proposed milestone date revision...".  So, if we evaluate the request for completeness (#1), this is probably not needed.

          1. Is bullet #9 about the recovery plan specifically? I thought it was only about specifying which dates differs from the official schedule. I'd like to have a detailed recovery plan, whose steps might be more granular than milestones.

            1. Greater granularity is fine for the project team, but for OPNFV purposes, I need to see the plan in terms of offsets from the "official" milestones, because that's what's approved by the TSC.  In addition, with 40+ projects to monitor, I don't have the bandwidth to track additional milestones

    2. I started a new paragraph for evaluation criteria.  Feel free to add to it.

      1. Thanks for starting it, I will add more points. I still have some questions:

        1. If the project won't make the release date, does it make sense to grant an exception?
        2. How do we handle dependent projects? Do they get an exception automatically if the project they depend on gets one?
          1. I think that it depends on the circumstances, but probably not.  However, I would like projects to affirm that they intend to meet the release date.
          2. I think that we should handle dependent projects on a case-by-case basis. I think that there are too many permutations to develop a specific process, in advance.
  8. I suggest to add to the evaluation criteria:

    2. The recovery plan is addressing all affected milestones, risks and the effects on other projects. It has a reasonable probability to succeed.