Well, they are not all equal. The “team decision points” in particular are not expected to last a long time. If they are, then the team clearly has not reached any form of consensus, and hence we should go back to the prior stage and not try to advance.
Clearly not all RFCs are equal. But I do think we should use this same process for all RFCs. My expectation is that smaller RFCs will just move quickly through the initial phases, since there won’t be a need for extended “spitballing” – in an extreme case, perhaps we’ll just jump directly to the “Draft” stage in one step (which is essentially the same as the process today, in that case, except that discussion is taking place on a distinct repository instead of a pull request).
I too was initially skeptical, but I don’t think your examples are prove very much (in fact, I don’t even think they are necessarily problems – though the delegation example is interesting!).
For example, the “fields in traits” repository is mostly dead – but then, the PR was dead too! I think you are correct to say it is languishing until somebody has time to work on it, and that’s ok. In fact, it’s anticipated. This is the “prioritization feedback” I was talking about – it’s fine for a design to hang out in the Spitballing phase until some team champion has time to focus on it.
(I do think we want to be careful to avoid artificial scarcity – it can be easy to forget that throughput problems can be resolved by growing the team as well – but this is no different from today either.)
I think that the NLL design would have benefited a lot from having a repository that we used from start to finish. As it was, the repository was helpful even at the late stage in which it was created. That is not an RFC where I expect a wide set of contributors as it is deeply technical.
The delegation case is more interesting. I can’t speak to the “crowdwritten” problem, I’ve not looked in detail at the RFC. It can be a challenge to develop things in an open way but keep a central vision. I don’t know what’s the solution there.
In contrast, though, the existing experience of using a single PR has produced pain in many, many instances. Anything remotely complex becomes a huge bear to manage. GitHub starts hiding key comments. Summaries kind of help but only so much.
A single PR feels “ok” if the RFC is short and the discussion simple – but in that case, I would expect that the repository would just be very simple, and that doesn’t seem like a problem?
