More concise wording for expedited releases #462
Conversation
| The most obvious example of an exceptional circumstance would be for a fix for a | ||
| publicly known or critical, easily exploitable security issue. Everyone will probably have a different definition | ||
| of what an exceptional circumstance is, but ultimately it is down to individual | ||
| PMCs to decide for their project. |
There was a problem hiding this comment.
A key motivator for the previous change was to provide an explicit example.
There was a problem hiding this comment.
Changed this to clarify that the PMC can decide, which says the same as previously but in a more precise & concise way.
| ASF projects are made up of distributed teams, in multiple time zones and volunteers | ||
| with lives and jobs and the rationale behind 72 hours is to try and give all | ||
| members of a project the opportunity to take part in the decision to release. |
There was a problem hiding this comment.
Adding this additional explanation was a deliberate decision.
There was a problem hiding this comment.
As @markt-asf said, this came out of the threads on members@ and at least a few people wanted any explanation of why for the 72h period. I added the paragraph as part of building a consensus on changing the docs, but personally I'm fine with removing it.
There was a problem hiding this comment.
The explanation is present above, "release votes SHOULD remain open for at least 72 hours, to give PMC members enough time to participate.". Re-adding it here is a duplicate, which I think should be avoided in a policy document.
There was a problem hiding this comment.
If you want to make sure people don't miss the reasons for 72 hours if they read just this section, maybe change "The review and voting period for a release" to "The review and voting period for a release (72 hours by default, see above)" ? I think it's better to avoid duplicating information in such a document.
There was a problem hiding this comment.
+1 to adding the text in parentheses. I'd still like to see the "multuiple timezones and volunteers with lives and jobs" text in there somewhere. Maybe more it (or something like it) to the paragraph that explains the 72 hour default?
There was a problem hiding this comment.
Good point, I have re-added that bit in commit #03f33d9
| Emails calling for a Release Vote that run for less than 72 hours MUST include | ||
| Emails calling for a Release Vote that runs for less than 72 hours MUST include |
content/legal/release-policy.md
Outdated
| Release votes SHOULD remain open for at least 72 hours. See the next | ||
| [Expedited Releases](#expedited-releases) section when considering a reduced | ||
| voting period. | ||
| Unless there are strong reasons to expedite a release, as described below, | ||
| release votes SHOULD remain open for at least 72 hours, to give PMC members | ||
| enough time to participate. | ||
|
|
||
| #### Expedited Releases {#expedited-releases} | ||
| As stated above, the normal policy for releases is to allow 72 hours for | ||
| release reviews and votes, however the review/voting period for a release | ||
| can be reduced in exceptional circumstances. | ||
| The review and voting period for a release can be reduced in | ||
| exceptional circumstances. |
| PMCs SHOULD give as much notice as possible to their project members | ||
| when doing an expedited release. | ||
|
|
||
| Projects SHOULD give as much notice as possible for an expedited release in | ||
| order to give project members a chance to make time to participate in the | ||
| decision. | ||
|
|
| This policy already states that deviations from normal policy MUST be reported to | ||
| the Board, but it is worth emphasising this here specifically for release votes | ||
| with a reduced voting time. Unless there are pressing reasons to inform the Board | ||
| earlier, reporting can be done in the project's next scheduled board report. | ||
|
|
||
| Expedited releases are deviations from normal policy, and as such MUST be reported | ||
| to the Board, in the project's next scheduled Board report, unless the PMC wants | ||
| to report earlier. |
That's not the intention, my aim was to simplify the wording, which I think is important for a policy document, without making any material changes |
| Unless there are strong reasons to expedite a release, as described below, | ||
| release votes SHOULD remain open for at least 72 hours, to give PMC members | ||
| (volunteers spread around multiple time zones, with lives and jobs) | ||
| enough time to participate. | ||
|
|
There was a problem hiding this comment.
Does not read well to me. I think the last two lines should be swapped
Sorry that I missed the discussion in PR #457 - here's a more concise version of the expedited releases explanation. I think it doesn't change the meaning, but hopefully says the same in a simpler way.
Preview at https://www-expedited-concise.staged.apache.org/legal/release-policy.html#expedited-releases