tc39
Document req. for changes to stage 3 proposals
I can't find this requirement documented anywhere, but honestly, I can't recall how I came to believe that it is in fact a policy. @ptomato or @justingrant may have some evidence since they have recently requested consensus for normative changes to the stage 3 Temporal proposal and plan to do so again next week.
/cc @ljharb
While we're making changes, it'd be good to clarify the role of the advancement deadline for normative Stage 3 changes. Copying from chat:
justingrant If "how we work" is being updated, one good thing to include would be how the proposal-advancement submission deadline affects normative changes for proposals not looking to advance, esp. during Stage 3 where implementers are actively finding bugs and bringing up issues. Concrete example: we discovered a Temporal spec bug several days after the deadline. Should we include it in our "Stage 3 update" slides next week?
shu i feel like how it works in practice is add whatever you want with an hourglass emoji to make it clear it's a late addition leave it to chairs to deprioritize as needed if you're asking about discovering new info after an agenda item has already been added and whether that new info can be folded into the existing agenda item, that sounds straightforwardly fine to me
The deadline is only for stage advancement, so for other agenda items, you can update your slides (or provide them) at any time. Normative PRs, for example, do not need to be in by the deadline, so consensus on normative changes to a proposal that's not seeking stage advancement wouldn't need to be either.
Also, stage advancements added after the deadline can still get consensus - they just may be rejected solely on the basis of missing the deadline - so the deadline shouldn't prevent adding new information anyways.
I don't mean to suggest that this is the current policy in any way, but I'd like to suggest that we adopt as our guideline that any normative changes, either to the standard or to Stage 3 proposals, should be added to the agenda before the deadline, so that delegates (and implementors in particular) can have a good picture of what's on the agenda in advance, so that they know whether they need to be there and have enough time to form an opinion.
I know this isn't currently a requirement, but I've been trying to treat it as if it is for myself, out of courtesy towards implementors of Temporal.
In other words, I think it'd be a failure of our process if I were to add a normative PR this coming Sunday, especially a potentially controversial one, and push for a resolution as early as Monday. I know people are free to block it anyway if they feel they didn't have enough time to think about it; but I don't think that's an ideal situation, since it puts the burden on the delegate who felt blindsided, and not on me, where I think it belongs.
Normative PRs to the spec sometimes come up last minute, so it'd be a bit constraining to require a 10 day notice, and normative changes to stage 3 proposals are supposed to be rare - but your suggestion seems like a reasonable additional PR to the process doc to bring to plenary for consensus.
There is actually no mention of the agenda deadline in the process document, so I added it to the agenda template (https://github.com/tc39/agendas/pull/1073) instead.
We could relax the "must" to a "should" for normative PRs that come up less than 10 days before the plenary, but my feeling is that this way it's a better reflection of who the burden should be on. If something arises 1 day before the plenary, then the burden can be on the presenter to acknowledge that and ask for delegates' cooperation in a situation where it's urgent that it be presented anyway.
I've added this to the January agenda and volunteered to present it: https://github.com/tc39/agendas/pull/1104