Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Component/s: Process Doc
    • Labels:
      None

      Description

      1.3 JSR DEADLINES specifies that JSRs must reach Early Draft Review within 1 year, Public Review within 2 years, and Finale Release within 3 years, or else be subject to a JSR Renewal Ballot. Are these times appropriate, or should we shorten them?

      Also, we've now decided to add a similar timeout for Maintenance Releases (not yet implemented.) The current suggestion for that is 90 days. Is that the right time?

        Issue Links

          Activity

          Hide
          keilw added a comment -

          EDR somewhat sooner sounds reasonable. What value, e.g. 6 or 9 months, please suggest if you feel the same. Given the other two values all seem based on the same starting point, adjusting those to something like "Public Review within another X months/year" followed by "Final Release within another X months/year" sounds like a logical consequence.

          That also better deals with situations where a PR of Final Draft has to be repeated. Whether or not the original time should be granted for that, I am not sure. We should avoid stretching it too far, but I guess steps like the Reconsideration Ballot should cover that and avoid too many failed attempts of a Public or Final Draft.

          Show
          keilw added a comment - EDR somewhat sooner sounds reasonable. What value, e.g. 6 or 9 months, please suggest if you feel the same. Given the other two values all seem based on the same starting point, adjusting those to something like "Public Review within another X months/year" followed by "Final Release within another X months/year" sounds like a logical consequence. That also better deals with situations where a PR of Final Draft has to be repeated. Whether or not the original time should be granted for that, I am not sure. We should avoid stretching it too far, but I guess steps like the Reconsideration Ballot should cover that and avoid too many failed attempts of a Public or Final Draft.
          Hide
          pcurran added a comment -

          From Bill Shannon:

          90 days is too short.

          We often file MRs well in advance of the final release of the RI for the
          platform. Knowing that the MR is approved and all we have to do is deliver
          it helps reduce risk for the platform delivery. Being forced to submit all
          MRs within 90 days of the final release, when we're trying to stabilize the
          release, introduces unnecessary risk.

          I greatly prefer the previous suggestion of asking the ML to specify when
          the final materials for an MR will be delivered, and otherwise using the
          general "JSR has failed to make progress" timeout mechanisms.

          90 days between FAB and FR might be reasonable, and I understand this introduces
          an asymmetry between a JSR and an MR, but it reflects our desire for MRs to be
          low risk lightweight events.

          Show
          pcurran added a comment - From Bill Shannon: 90 days is too short. We often file MRs well in advance of the final release of the RI for the platform. Knowing that the MR is approved and all we have to do is deliver it helps reduce risk for the platform delivery. Being forced to submit all MRs within 90 days of the final release, when we're trying to stabilize the release, introduces unnecessary risk. I greatly prefer the previous suggestion of asking the ML to specify when the final materials for an MR will be delivered, and otherwise using the general "JSR has failed to make progress" timeout mechanisms. 90 days between FAB and FR might be reasonable, and I understand this introduces an asymmetry between a JSR and an MR, but it reflects our desire for MRs to be low risk lightweight events.
          Hide
          pcurran added a comment -

          Responding to Bill Shannon's comments...

          I expected you to say that 90 days was too short - that's why I asked. I also understand the complications involved in synchronizing everything for a platform JSR.

          However, I'm not sure what you mean when you say:

          "I greatly prefer the previous suggestion of asking the ML to specify when the final materials for an MR will be delivered, and otherwise using the general "JSR has failed to make progress" timeout mechanisms."

          If you mean that MRs intended to be included in a platform JSR should be subject to the same timeouts as the platform JSR itself then that makes sense (and is what I was planning to suggest.)

          However, for MRs not intended to be included in a platform we need something other than "the timeout date is whatever the ML says it is." (We'd just get a bunch of MLs telling us that they plan to deliver before the end of the century.")

          How about saying that the final release must be made within 90 days or - if the MR is to be included in a platform JSR - before the platform JSR itself is completed?"

          Show
          pcurran added a comment - Responding to Bill Shannon's comments... I expected you to say that 90 days was too short - that's why I asked. I also understand the complications involved in synchronizing everything for a platform JSR. However, I'm not sure what you mean when you say: "I greatly prefer the previous suggestion of asking the ML to specify when the final materials for an MR will be delivered, and otherwise using the general "JSR has failed to make progress" timeout mechanisms." If you mean that MRs intended to be included in a platform JSR should be subject to the same timeouts as the platform JSR itself then that makes sense (and is what I was planning to suggest.) However, for MRs not intended to be included in a platform we need something other than "the timeout date is whatever the ML says it is." (We'd just get a bunch of MLs telling us that they plan to deliver before the end of the century.") How about saying that the final release must be made within 90 days or - if the MR is to be included in a platform JSR - before the platform JSR itself is completed?"
          Hide
          Bill Shannon added a comment -

          If the ML proposes a delivery date that's ridiculously far in the future, the
          EC should vote against it.

          I'd be fine if the MR->final bits and FAB->final bits timeout defaults to 30
          days, as long as there's a way to request a different timeout and the EC gets
          to approve it.

          And I'm a bit worried if missing the timeout means you automatically go back
          to the previous step, without a chance to update your timeout (e.g., because
          your release slips). But on the other hand, I'm not sure I want to define
          another EC ballot type to handle timeout updates!

          Show
          Bill Shannon added a comment - If the ML proposes a delivery date that's ridiculously far in the future, the EC should vote against it. I'd be fine if the MR->final bits and FAB->final bits timeout defaults to 30 days, as long as there's a way to request a different timeout and the EC gets to approve it. And I'm a bit worried if missing the timeout means you automatically go back to the previous step, without a chance to update your timeout (e.g., because your release slips). But on the other hand, I'm not sure I want to define another EC ballot type to handle timeout updates!
          Hide
          pcurran added a comment -

          The balloting process is already defined (JSR Renewal Reconsideration Ballot) though this will need to be generalized to cover Maintenance Releases as well as JSR development milestones. We wouldn't cancel a JSR or bump a MR back to the previous stage without review.

          So: is this a reasonable summary of your proposal?

          The ML chooses the deadline (if nothing specified, it defaults to 30 days.) This would presumably be done when the materials were submitted for the Maintenance Review. If the EC feels that the deadline is unreasonable they're free to vote 'no.' I'm sure that a deadline of "whenever the platform JSR that will include this update is shipped some time next year" would be an acceptable deadline. Alternatively, "we're planning to announce this standalone JSR update at our product show six months from now, but we want to make sure we have everything ready well in advance" would also be acceptable.

          If the deadline is missed we go into the JSR Renewal Reconsideration Ballot process. In practice I'm sure the PMO would remind the ML, and would be flexible if they were told "we're a few days late, but it's coming Real Soon Now."

          Show
          pcurran added a comment - The balloting process is already defined (JSR Renewal Reconsideration Ballot) though this will need to be generalized to cover Maintenance Releases as well as JSR development milestones. We wouldn't cancel a JSR or bump a MR back to the previous stage without review. So: is this a reasonable summary of your proposal? The ML chooses the deadline (if nothing specified, it defaults to 30 days.) This would presumably be done when the materials were submitted for the Maintenance Review. If the EC feels that the deadline is unreasonable they're free to vote 'no.' I'm sure that a deadline of "whenever the platform JSR that will include this update is shipped some time next year" would be an acceptable deadline. Alternatively, "we're planning to announce this standalone JSR update at our product show six months from now, but we want to make sure we have everything ready well in advance" would also be acceptable. If the deadline is missed we go into the JSR Renewal Reconsideration Ballot process. In practice I'm sure the PMO would remind the ML, and would be flexible if they were told "we're a few days late, but it's coming Real Soon Now."
          Hide
          Bill Shannon added a comment -

          Yes, that seems reasonable to me.

          Show
          Bill Shannon added a comment - Yes, that seems reasonable to me.
          Hide
          pcurran added a comment -

          Despite lengthy discussion at the September f2f meeting we failed to reach agreement.

          Some argued for much shorter time-out deadlines in order to "send a message" that we expect rapid progress. Others arguing for regular "reviews."

          Patrick pointed out that we can't impose too much of a burden on the PMO, and reminded everyone that the purpose of this change is to permit us to deal with JSRs that are obviously stalled or inactive rather than to encourage people to work faster.

          Needs further discussion at the next Working Group meeting.

          Show
          pcurran added a comment - Despite lengthy discussion at the September f2f meeting we failed to reach agreement. Some argued for much shorter time-out deadlines in order to "send a message" that we expect rapid progress. Others arguing for regular "reviews." Patrick pointed out that we can't impose too much of a burden on the PMO, and reminded everyone that the purpose of this change is to permit us to deal with JSRs that are obviously stalled or inactive rather than to encourage people to work faster. Needs further discussion at the next Working Group meeting.
          Hide
          pcurran added a comment - - edited

          As agreed during the September 21 Working Group meeting, we're going with 9 months plus 12 months plus 12 months. The relevant text now reads:

          "If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay.

          I'm now closing this issue

          Show
          pcurran added a comment - - edited As agreed during the September 21 Working Group meeting, we're going with 9 months plus 12 months plus 12 months. The relevant text now reads: "If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay. I'm now closing this issue
          Hide
          Bill Shannon added a comment -

          You said 9+9+9, but you wrote 9+12+12. Which did you intend?

          Show
          Bill Shannon added a comment - You said 9+9+9, but you wrote 9+12+12. Which did you intend?
          Hide
          pcurran added a comment -

          Fix typos

          Show
          pcurran added a comment - Fix typos
          Hide
          pcurran added a comment -

          Fixed the comment that Bill referred to. I meant 9+12+12

          Show
          pcurran added a comment - Fixed the comment that Bill referred to. I meant 9+12+12

            People

            • Assignee:
              Unassigned
              Reporter:
              pcurran
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: