Process proposal: immediate rejection of deliberately open-ended RFC

[pnkfelix]

Process proposal: Encourage immediate rejection (i.e. "close the Pull Request") of deliberately open-ended RFC, to force authors to write their RFC's in a way that leads to a directed conversation, rather than confusion about what the actual proposal is.

---

First off: I am going to be picking on one RFC in particular, because it is the one that most recently bothered me on this point.

But, most important: It is not the first RFC to make this mistake, and I am definitely not trying to pick on the author of that RFC personally.

Okay, so, the motivating example: I was a little irked when I read this in the most recent struct literals RFC (#841):

Pick a syntax for structs. This syntax will be the One True Syntax for everything remotely struct related. There are two requirements ...

and then the "design" proceeds to show the two requirements, and sketch ... maybe three? ... different proposed syntaxes, none of which were described very clearly, and more text was devoted to the drawbacks of two of the three design sketches than to the actual description of any of the three.

Then when I tried to engage in discussion about the RFC, and assumed (based on my admittedly cursory reading of the RFC assuming that the second presented design sketch was the actual proposal, I saw responses to my comment that assumed that the third sketch was the actual proposal.

This is not an efficient way to propose a concrete change to the language, and is not an appropriate use of the RFC Pull Request system. I think this sort of open-ended discussion is better off put on one of the discuss forums, forming a set of alternatives, choosing one to present as the concrete design and listing the others in the Alternatives section (since that is what that section is for).

If for some reason you want to insist on using the RFC repo for your discussion (e.g. you believe that the forums do not get enough eyeballs), then I still think that filing an issue would be a better way to figure out which design to write up formally, rather than filing a PR that has no chance of being merged since it is, to put it simply, an ill-formed document.

---

As a quick ending note: I'm not the only one who thought upon reading this RFC that it was ill-formed in showing multiple alternatives in the "Detailed Design" section. See for example:

• Changing Struct Literals #841 (comment)

[eddyb]

👍 if we are willing to reopen RFCs once the author has restated their intentions clearly (though opening a new PR isn't much of an issue, I guess).
For pre-RFC discussion and bikesheds, we should point to the internals discuss forum, and there should be no confusion as to why a suggestion might be rejected/postponed.
Besides, creating a RFC without some community input tends to end with a serious backlash so we should discourage that, too.

[steveklabnik]

Yes, I generally agree. A PR with an RFC should be about something concrete. Discuss or issues is the best place to build consensus and hash out issues before arriving at a specific proposal.

[Gankra]

Yeah I think this is a good idea. I'm often tempted to field two "equal" proposals, or one conservative and one crazy proposal. But I think it's generally more constructive to force the author to actually think about the problem and decide that one is The One True Solution. Even if they pick what history will regard as the "wrong" solution, it at least streamlines the process and keeps everyone on the same page. This policy would give a proper nudge of "no really, you need to work out the details".

We have an alternatives section to toss in the "loser" ideas, and it's not unheard of for the loser and winner to get swapped during discussion. e.g. see #832, where I presented the conservative choice of just returning from_elem verbatim, with the "crazier" alternative of upgrading vec! to replace it. The crazy one gained consensus and the RFC swapped them. Painless.

[iopq]

Well, I would then write it and propose Foo { x => y } which might get rejected by people who think that Foo { .x = y } is the One True Syntax.

The point of the RFC is to first agree that the syntax should change. If 40% of the people want it to stay the same, 30% favor my syntax and 30% favor the C99 syntax, then neither of the alternatives would have a majority or even beat the status quo. Either syntax would look "rejected" if submitted as an RFC.

That's why I discussed three alternatives and tried to reject one (that was already rejected in earlier RFCs) and tried to show how patterns with structs should use a directional syntax for clarity.

Shouldn't there first be a decision on whether to stay with the status quo vs. change it? Because if it's decided to be changed, then people can bikeshed about it later and decide the actual syntax.

[pnkfelix]

@iopq the team has asked past RFC's to be revised/rewritten using one of the listed alternatives instead of the original detailed design. I think that is a better strategy (choose one primary one to present, but also list the alternatives in as much detail as you'd like) rather than trying to present a smorgasborg of options.

[pnkfelix]

@iopq of course, I am sympathetic to a (hypothetical) response that it takes time to author an RFC (especially a well-written one), and therefore it seems wasteful to spend time developing a detailed preferred design only to have it rejected because any change is deemed worse than the status quo.

I would say the answer to that is to file an issue, and bring that issue to the attention of the core team, in order to find out whether there is general support for putting in such a change in the short term.

(Of course, then there is a tension between how much detail to put into such an issue's description, since it needs to have enough detail to convince the team that change is required, but if you need a lot of detail, then one might ask why not write an RFC in the first place. I do not have answers to all such questions, but I still think there are better ways to go about this.)

[nikomatsakis]

👍 I think there are ways to write an RFC that still picks a favorite but lays out the alternatives, such as what was done in #823.

[glaebhoerl]

Possibly on pure process grounds this might be a good idea, but I have misgivings about the accompanying attitude, e.g. "Encourage immediate rejection...", "force authors to write...". The RFC process from the submitters' side is frightening, arduous, and nerve-wracking enough as it is, with the writing itself, the debate (with people inevitably emerging from the woodwork to oppose just about any proposal), the loss of control, the low odds of success, the shortage of reviewers' available time and attention, the potential for opacity and seeming-capriciousness in the decision-making process, and so on. I don't think we really need to add to that, or that a dearth of pretexts for arbitrarily rejecting an RFC is one of the more pressing problems.

This is (at least nominally) a community project. Nobody is required to volunteer their scarce time and effort for its advancement, and few have very much to gain from it personally. As such, putting the burden of process on volunteer contributors' shoulders is putting it in the wrong place. And saying "we refuse to consider your ideas to improve Rust unless you correctly jump through these hoops we've set up" does not, substantively, make sense.

I would be less concerned if the process had a history of functioning smoothly and pleasantly, but in reality its track record is mixed at best, or perhaps if this proposal were framed in terms of providing greater clarity and proactively guiding ("shepherding") contributors through the various steps and discussion fora deemed appropriate, instead of merely as a way to close more RFCs faster.

As regards the actual proposal, I know that this is ancient history and that things have been getting at least somewhat better, but I did, personally, have an experience (#10) where based on similar considerations as laid out by @pnkfelix, out of multiple possible variations I chose to put one in the main text and the rest in the alternatives, even though I didn't personally have a strong preference among them, only to have the RFC rejected (in part) based on objections to details and defaults as they were in the main text, without any seeming consideration given to the equally plausible variations and default-flips also mentioned. After that I very much intended to pursue the "I don't care, you guys choose" approach of listing all the alternatives up-front in the main text if I ever had to face a similar decision again, and I find it hard not to sympathize with others such as @iopq in a similar predicament. The occasional tendency towards deciding RFCs (in part) based on temperature-taking of the accompanying discussion is also not irrelevant here, as that indirectly generates a similar dynamic, where commenters (at least can't be presumed not to) react based on the main text, and the core team in turn considers the overall attitude of those commenters, as @iopq observes. All of this may not feel like much of a problem when you're in a position to make the process work well for you, but please do consider that it might feel different coming from the outside.

tl;dr I'm not sure I have any concrete objection to this proposal in particular, but I'm worried about a tendency towards preoccupation with process over substance in general. (I also didn't expect this comment to grow so long.)

[pnkfelix]

@glaebhoerl this proposal, as written, may be biased too far towards "try to close RFCs as soon as possible" and not enough towards "try to help the author produce a better document"

[pnkfelix]

(closing; I'm not interested in causing more ill will from the community.)