docs: Clearly document our backport approval process#249
Conversation
There was a problem hiding this comment.
Reviewed in the spirit in which the PR was submitted: documenting our current practices. Obviously there are strong opinions on what future practices should be resolving that is for a future PR 🙂
However I would point out that our current practice's point 5 is unenforceable: say a new backport feature causes breakage in an unrelated feature that shares some code paths, so the WG reverts the PR to remove the feature. Removing a feature is a breaking change, so we wouldn't be able to do another release on that major series until the feature was reinstated.
We should also ensure that async emoji-voting has a voting window long enough for everyone in the WG who wants to vote. I'm specifically thinking of the WG members who live or travel outside of CONUS. We wouldn't need to leave voting open if they're not interested; but if they are, they should have their chance
6 participants
This PR updates our documentation on our backport approval process to better line up with our current practices as well as adding the option of approving backports ad-hoc.