How can we, as a community, make the RFC process less draining?

community
22

Why would it not work? Those "Ideas Changes" are separate PR's. They may conflict either textually or semantically. Once one is accepted and merged, if the other has any textual conflicts, it automatically is rejected and requires the originator to refine it to the new content of the document. If it conflicts semantically, but not textually (which seems almost impossible), then it will be rejected by the author once reviewed.

I neglected to cover that. That should be handled by a PR that puts the questions in the context of the RFC document. Thus, it can be reviewed easily by the author and then, either answered by adding the necessary answers to the document either in place of the questions, or with the questions and their answers as appropriate.

I agree, but I don't think I was proposing "Wild Forking". What I'm saying, is that if someone, or some group, believes a given RFC is way off base, they can fork it, work out their version of it, without directly bothering the author of the original RFC, then make PR to the original with their explanation as to why their version is better. The original author could accept the PR after discussion, or reject it. In that case, their are now two competing RFC's for similar functionality. It would be expected that the language/compiler team wouldn't spend time on forks of an RFC until they considered the final version (as submitted by the author) of an RFC and decided it wasn't able to be accepted in the current form. They could then choose to look at forks to see if any of them resolved the issues the teams felt needed resolved and accept one of them instead. This should discourage forking in favor of working with the original author to resolve issues as it would be understood that language/compiler teams would not invest time on forks unless they first rejected the original.

23

How would one then express dissatisfaction (for example that the whole RFC is a bad idea ie due to making syntax complicated or no good trade-off)? Are you sure this will not create tribalism and wild forking? And what about disruptive people or RFC authors with a bad day, who might just close the PR without clarification?

PRs become sadly not very visible once you close them, so I dont see alot advantage over a review. If you require users to only write reviews or meta on status, you will likely have the same outcome.

24

As I mentioned above, through "Negative RFC" or by a PR that calls out reasons why the RFC should be simply closed and rejected:

25

I guess your idea could work and should be tested and evaluated for a limited time before making a decision.

26

I think that would be putting too much of a burden on RFC rejections. Do you really want people to write a whole RFC just to shut down a proposal, say, to add a segfault keyword?

27

That wouldn't be specifically necessary. I know that's just an example, but I'd expect the "counter RFC" to lay out some set of criteria a word has to meet to be reserved as a keyword. If said criteria rules out segfault, then the RFC for segfault as a keyword would be dead until it resolves the concerns officially accepted as policy by accepting the "new keyword requirements" RFC.

It's generally considered good policy to say why you don't accept some extension to the product. Creating a "negative" RFC is "just" formalizing whatever policy/belief that you are using to reject the undesired RFC.

A negative RFC wouldn't be "reject RFC #NNNNN", it'd be "this problem space is out of scope to be addressed by core language features; here's why", or "this solution space is out of scope for core language features; here's why", or "here's a set of requirements for language features in this space; here's why." All of those necessarily rule out some potential features/RFCs, but do so in a constructive way. (And if the things their argument is based on ever change, the opinions accepted within can be amended.)

(Disclaimer: this is just explaining/exploring the idea, and should not be taken as endorsement of the idea.)

(Disclaimer²: the above disclaimer does not mean the author is against the idea, just that they're not putting forward an opinion yet.)

7 Likes
28

No, I believe I said clearly that was not REQUIRED, but was an OPTION to shutdown not just the given RFC, but any RFC in the future for the same feature. Other simpler options would be allowed as well:

For example, if someone were proposing to modify Rust to allow multiple mutable references without "unsafe", that would be a violation of the core goals of Rust and should be rejected. Similarly, any future RFC should be rejected as well and the accepted negative RFC can be a document that provides immediate justification so that there isn't repeated debates of things that will never be allowed into Rust.

1 Like
29

The RFC process is the last step in the chain: except in rare cases, once an RFC is approved, it's part of the language exactly as written. It's necessary for the RFC process to be a huge hurdle to overcome, because every change to the language has a multitude of costs associated with it.

The reality is that the vast majority of ideas proposed would (when the costs are taken into account) be for the worse. My own ideas as much as anyone elses. As Rust improves and matures, that bar will continue to get higher.

Instead of making the RFC process less draining, or turning it into some kind of brainstorming session, there need to be additional steps before the RFC process, ideally involving multiple people. I believe there have already been many attempts to do this: eRFCs, working groups, etc. But perhaps the process could be better documented.

3 Likes
30

Hi all,

I'm very excited to see this thread. Sorry I haven't participated more. This is a topic near and dear to my heart, and I'll admit to some frustration that we haven't made much more progress this year, as this was something that I really wanted to push through. I read all the comments with avid interest and just wanted to give some of my current perspective. That said, my initial drafts for comments on this thread were each super long, so I'm going to cut those and try to keep it short.

To start, my overriding goal has been to try and move RFC drafting and design iteration out from the RFC repo and into groups. I think that this can enable a more collaborative form of discussion, but also allows for better ways to keep the lang-team updated. It does, I think, also imply a bit more selectiveness -- the lang-team can only pay attention to so many things at once. I think that being clear about which things we are paying attention to and which things we are not is overall good.

But it does raise the question of where that design work should go. Right now, it sometimes happens that people post an RFC and there is a lot of really fruitful back-and-forth from the community. But once that "final form" is reached, the proposal typically just stalls, sometimes getting nominated. I think this parallel design is often good, though it's not always good -- sometimes it's stressful and overwhelming for folks. I'm not sure that the RFC repo (on a PR) is the right place for it to take place. It might be better e.g. if people made external github repositories for the proposal, or did the iteration over a series of internals threads.

That said, I recognize that the lang-team hasn't been doing a good job giving feedback to MCP proposals. I'm trying to get on top of that and integrate them into our triage process etc. We're also doing a "backlog bonanza" where we are spending time every week going through the older RFCs and issues.

I've also been experimenting with the best way to expose the things we're working on. You might be interested, for example, to see the lang team project board, which aims to show active projects as they move towards stabilization. This is still a WIP, but I hope that it can eventually be a kind of "go to" source to find out what's going on.

One thing I heard in this thread that really interested me was thinking about how to change the nature of feedback. I feel pretty strongly that github PRs are a bad way to exchange design feedback. I think the idea of having bots that enforce some fairly crude criteria -- i.e., no small comments, or only so many comments per person per day, things like that -- might be a really nice way to help steer feedback, combined with some guidelines. I was intrigued by @burntsushi's idea of staging the comments on an individual RFC, it reminded me of the proposal that @carols10cents put forward some time ago to have an initial "period of reflection" on an RFC where people couldn't comment at all.

One thing I've thought about is running contentious RFCs through a more deliberate process. The idea would be something like:

  • Post the RFC as a blog post or in some form that doesn't permit comments.
  • Have people submit comments via a google form for a certain period of time.
  • Publish all comments, along with responses, and publish a new draft of the RFC.

Somewhat similarly, I'm a big fan of closing RFCs when you've got enough feedback, and then re-opening a revised draft with a summary of what feedback you incorporated. (I'm thinking of doing something similar to RFC 2936, actually.)

12 Likes
31

One further update:

I've just pushed a bunch of new content to https://lang-team.rust-lang.org/proposing_a_project.html describing the current status of the lang-team project process (I'm trying to replace the "MCP" term with just "project proposal"). This is still something of a work-in-progress, but I hope it conveys some of the ideas we're working towards. You can also view the active projects page, which describes the stages more concisely, and links to the project board.

One particular thing is that I'm integrating the step of "review proposals and provide feedback" into the triage process and so I am shooting for a goal that we provide feedback quickly, within a week or two. I've also revamped the project board, as I mentioned earlier, so that it identifies active projects at each stage.

One thing I would really like is to have more regular blogging and public updates on the status of each project, but one thing at a time. That's really a lot of work. This is another reason to push more towards groups: often there may be someone within the group who can write updates.

As always, feedback requested. =)

5 Likes
32

That seems very useful! One good thing about the RFC repo is that you can subcribe to the repo to be notified about new RFCs to the language. It would be useful if there was a way to subscribe to new project groups, and if that mechanism was widely publicised, so that concerns from users who are not directly involved in the project group can be raised early, and to avoid the project group becoming too siloed. This way, by the time the RFC is written, most concerns should already have been considered, and the findings included.

3 Likes
33

That is a good point. I am personally watching a bunch of github repos like GitHub - rust-lang/unsafe-code-guidelines: Forum for discussion about what unsafe code can and can't do and GitHub - rust-lang/const-eval: home for proposals in and around compile-time function evaluation, but that's kind of an "all or nothing" scattershot approach since different groups seem to either do everything or nothing on github (for example, I feel excessively well-informed about what UCG is up to, but I have no idea if the grammar WG has made any progress at all). Some lower volume communication mechanism that all groups agree to use consistently would be tremendously valuable (maybe Inside Rust blog posts with a group tag?).

3 Likes
34

(Because we haven't really)

1 Like
35

This might depend on the specific circumstances, but I've experienced some downsides to this approach as well. What about the comments that didn't get incorporated? (And not all comments are necessarily "feedback meant to be incorporated": they can be general observations, counterarguments to suggestions by other commenters, etc.) Having to keep up with a sprawling RFC thread is a burden, but having to keep repeating the same point every time the discussion restarts in a new thread is also a burden. (Of course, one can choose not to, in which case consensus is achieved by attrition.) Especially now that GitHub has the ability to mark comments as outdated and hide them, that feels like a preferable approach to me.

36

There are things that are coming down the line on GitHub that we should keep an eye on such as GitHub Discussions and Pull Request Revisions that might help in this area.

3 Likes
37

These are exactly the kind of concerns I had in mind by proposing to use PR's against an RFC to facilitate rather than comments on GitHUB for the RFC PR. It allows a much better (IMHO) structured approach to evaluating and incorporating changes and requires a little more forethought and design on the part of someone wishing to have the RFC modified - either for clarification, or for purposes of changing substantively the problem space, solution space, or the overall solution to the problem

1 Like
38

I think the most sensible way to draft and discuss an RFC would be with a tool like Jira/Trello/GitHub Projects. There can be multiple threads, sorted into columns like "questions", "concerns", "alternatives", etc.

This makes the discussion better structured, so RFCs with hundred of comments remain manageable, and provides a nice overview. If someone has a concern, they can add it to the "concerns" column. If the concern has already been raised before, they can upvote it.

The RFC document can be short and informal in the beginning, but should be revised and extended over time. This should be collaborative (so more than one person can have write access). There's no need for a separate "exploration phase" or a Pre-RFC.

I think that the whole community should be involved from the very beginning, so everyone can provide early feedback. Once the RFC document is complete, all the feedback has been addressed and hopefully community consensus has been reached, the RFC is done. Then it's up to the lang team to decide whether the motivation is strong enough to outweigh the drawbacks.

3 Likes
39

The new PR links to the older one, so it's always possible to go back and read the full story. It's true that you lose some amount of context by creating a new PR, but we can do our best to carry over the key points (and counterpoints) either in the RFC text or in the new write-up that introduces the conversation. Just hiding comments is both a big drain and, in my experience, not really sufficient -- the idea is to provide a "fresh slate" for people to discuss from a new place, and I don't think that hiding comments has that effect. (I've tried to use hiding comments, it's very difficult to decide when the "right time" is, and then it's also more annoying to go back and find comments later and catch up on the full thread when you want to.)

Anyway, not a perfect solution, but a technique I think we could try more often.

1 Like
40

This is roughly what we are doing, at least some of the time. For example, the async foundations working group is iterating towards a Stream RFC in the wg-async-foundations repository -- you can see the tracking issue here, and there is a current draft.

I do though think there is some amount of...transparency missing. I don't know what I think the best way is for folks to "subscribe" and keep track of things, and we have to keep in mind how much work it is to publicize what is going on. We need mechanisms that are pretty simple and lightweight. Dedicated repositories help since folks can "watch" them, but it's not always great. (And sometimes the conversation occurs in a few places, e.g. some over Zulip, maybe some on Discord, and some over Github.)

This is certainly what I'm trying to address by working on the rust-lang repo and project board -- e.g., we've been posting comments in summary issues like this one, which mean that you can roughly follow along at the same level of detail as the lang-team itself. But...sometimes projects also have tracking issues in other places, or their own repo, and what seems like the best fit does seem to depend at least somewhat on the project itself.

2 Likes
41

I wholesomely agree with @Aloso

Would it be possible to easily create a new repo under the Rust organization (in order to have a central place to look for) for any new RFC?