Document number: P1999R0
Audience: EWG, LEWG
Process proposal: double-check evolutionary material via a Tentatively Ready status
Here's the problem, or a couple of them:
Sometimes (NOT all the time), we send material onwards
from EWG and LEWG and that material
and sometimes the last bullet is something we realize when
the design groups think the matter is design-wise settled
and ready for reviewing technical details, in other words,
off of LEWG/EWG's plate.
- was discussed with key stakeholders elsewhere
- ends up with surprises about bakedness of the design
- ends up with surprises about implementability and CWG/LWG
Raising concerns after a LEWG/EWG sign-off is awkward
and has a high overhead; it's a schedule disruption
and a distraction, albeit necessary. Sometimes such concerns
are noticed after the sign-off, and this paper doesn't suggest
that to change; rather, the author encourages CWG to continue
sending design material back to EWG eagerly, and encourages
LWG to do more of the same.
Here's a suggestion for a solution:
Let's make it our default
process that both LEWG and EWG, when sending a proposal
onwards, first make it Tentatively Ready, announce such transitions
loudly and widely, give it a (hopefully)
brief look at the next meeting, and if nothing particular
concerns anyone, flush it forwards.
And as always, that would
be a default process, and can be expedited if need be
or if there exists a high level of confidence that some
proposal doesn't need to wait.
Elaboration, and what we expect to happen in the double-checking
phase for Tentatively Ready papers
So, for an evolutionary group, here's our new proposed default process:
- Discuss a paper in the evolutionary group, find that it has consensus,
and the evolutionary group thinks it doesn't see anything that would
necessitate the paper returning to it.
- Mark the paper Tentatively Ready and announce it has such
status, putting especially the next group in the pipeline on
notice that such material is incoming. The announcement
is also expected to implicitly solicit review and feedback
from the audiences that weren't present in the discussion.
The most high-order bit, however, is that members of the
next group in the pipeline are not-so-implicitly invited
to review the incoming proposal, and they are given time to do it.
- For the next meeting, look at whether there was feedback,
and if not, send forward without further ado (this can be done
by The Chair), and if there was, discuss the feedback on the reflectors
and if need be, schedule a discussion for the feedback.
Here are examples of exceptions to the rule, situations where
we might think we can go straight to the next group:
In other words, while there's wiggle room for uncommon sense
decisions to not use the default process, let's do that when
there are strong indications that it's the right thing to do.
- a proposal has all the language/library designers that are
not authors or co-authors of the proposal frantically
nodding their head, saying it's the right thing, and
language/library technicians and wordsmiths agree
- a proposal is a smaller technical change and there's early
feedback from CWG/LWG saying it's a slam dunk
Is this a "slow things down" process change?
No. First of all, material forwarded from an evolutionary group to the next
group can't realistically be expected to be dealt with in the same meeting
by the next group, except in sunshine scenarios. Furthermore, if there
are no concerns raised, the material just moves without any face-to-face
time overhead or scheduling overhead. In case concerns were raised,
this process is arguably one with less overhead than having to punt things
back from what is supposed to be a wording review, or otherwise disrupt
a pipeline that was expected to be at a later stage.