I’ve been thinking that even before submitting a RFC to solve a problem, the problem itself should be defined.
That is, I think it would be valuable to start with an RFP (Request for Proposals) which describes a problem. The RFP would be discussed, the problem clarified, and then a decision would be made on what to do about it.
For example, I’ve seen several discussions on anonymous enums recently, where authors and participants have all investigated a significant amount of time and energy, notably bikeshedding syntax, even before the lack of anonymous enums was actually recognized as a problem. If we now end up deciding that actually, anonymous enums seem like a bad idea, then all that energy and good-will was wasted.
For another example, more extreme, consider the 2D Graphics proposal to the C++ Standard Library. It was reviewed multiple times over 3 or 4 years, each time receiving a lukewarm response and the committee asking for improvements/clarifications, for finally being rejected because 2D Graphics are not a good fit for the C++ Standard Library. Needless to say, its authors were terribly disappointed.
A process where first the problem need to be acknowledged would limit investment from all parties. Also, this is an excellent opportunity to simply postpone work on a problem, even before it started.
So the process would be first open a RFP, get it accepted, and then multiple RFCs can be opened referencing this RFC and proposing potential solutions of various scope. Also, even if the RFCs are rejected, a later RFC for this RFP will have all previous attempts at its fingertips immediately, rather than wondering whether their bibliography is exhaustive.
Examples of decisions on a RFP:
-
No: The problem described is not perceived as a problem. For example, the lack of M:N threading in
stdis deliberate. - Postponed: The problem described is acknowledged, but exploration of the solution space should be postponed for one reason or another. There may not be enough bandwidth, it may interact with another unstable or recently stabilized feature on which the team would prefer to gain more experience first, …
- Low-Bandwidth: The problem described is acknowledged, the team/WG does not have time to think on it right now, but is open to starting discussions, albeit at reduced bandwidth. Do not expect mentoring or low-latency shepherding.
- High-Bandwidth: The problem described is acknowledged, and there is commitment from the team/WG to see this through. Proposals are welcome, mentorship/shepherding is expected.