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

community
1

The Rust RFC process has repeatedly caused RFC authors to feel demotivated about contributing to the design of Rust. The "wave" of feedback they get when posting a RFC feels demotivaing and adversarial. This affects members of the official Language and Library teams. It presumably also affects newcomers that write RFCs, although I rarely read about their experience so it might be worse for them, or simply different, or better (although that would surprise me).

This problem might get worse when the comments are inconsiderate or in bad faith. However, it exists even when every single comment is constructive by itself. And even comments that are made in good faith can collectively come across as an intense debate in which the author feels responsible for "defending" their ideas against anyone who comes by. This tends to make their experience rather unpleasant. A situation which makes any contributor feel unhappy about contributing is a situation we should strive to avoid. However, this is not easy in this case.

Unfortunately, providing examples for problematic discussions risks reheating those particular discussions, which is even less pleasant (particularly for its authors and moderators). That's why (after I was made aware of this problem) I decided to keep my description of the problem abstract and without examples.

I never wrote an RFC myself. I recently voiced some concerns on one and later noticed that I might have been part of the "wave" of comments creating an adversarial feeling. I was contemplating how to learn from this and handle this better in the future, but I couldn't really find an answer. I'd like to ask for suggestions regarding the following questions:

  • How can the commenters to an RFC communicate in a tone that makes these discussions feel less adversarial and improves the culture of public collaboration?
  • What "volume" of feedback to a RFC is appropriate and sustainable? How can the commenters to an RFC (assuming the best of their intentions) control this volume while making sure every concern is eventually voiced?
  • How can we encourage behavior that mitigates these problems?
  • What other steps can we take to make the RFC process less draining, adversarial and demotivating?

Some notes:

  • The problem statement was influenced by experience reports by @josh, @mjbshaw, and @withoutboats. If they post something that's similar to my problem statement, that's because I copied from them.
  • Please, please do not make this about your "free speech" or anything like that. This is not about what minimal standard of behavior we should accept, but rather about how to go above that to actively make the community a better place. I'd like to learn something, not light a dumpster fire.
14 Likes
2

I think GitHub, as a medium, is perhaps part of the problem. But maybe another aspect of this is just the deluge of feedback one can get in a short period of time. And perhaps not just the amount of feedback, but also the kind of feedback. If I were to brainstorm without paying attention to any particular discussion medium or how pragmatic they are, then here are some quick ideas:

  • Request or enforce some kind of limit on how much feedback could be given within any particular time window. This could perhaps change over time. e.g., Maybe the limit is small at first, but expands.
  • Perhaps a per user limit, where any one person is only allowed to make a single comment in each 24 hour time period. But no limit on how many people can make comments.
  • Somehow restrict who is allowed to comment in a particular time window. (Although this seems problematic for a number of reasons.)
  • Add some kind of notice to the comment area that reminds users participating in the discussion to be first and foremost helpful in their feedback. That is, encourage folks to treat the RFC author as a collaborator or part of a team that moves forward together, rather than adversaries. (I think this is perhaps really hard advice to follow, even for me, and is pretty subtle.)
  • Add a notice of encouragement seen by RFC authors that warns them about the sort of feedback they might receive. Speaking from experience, I know that it can be helpful to have expectations set beforehand, which gives one a chance to mentally prepare for what's about to come. Not all RFC authors know what to expect.

I think most of those suggestions are fairly mechanical and could be done using tooling, but perhaps there are process or procedural things we could do too. For example, if I submitted an RFC and my first bit of feedback was 20 comments about minor grammar mistakes or typos, I'd find that pretty deflating. Not because such things aren't important to fix, but rather, because they aren't important right now. The RFC is likely not in its final form, so that kind of editing just isn't that helpful right now. It's most helpful just before the RFC is about to be merged (if it's accepted).

Perhaps that can be generalized. Maybe one way to limit or focus the feedback is for an RFC to go through stages where only certain kinds of feedback are allowed. We kind of already have that today with "pre-RFCs," where some kind of loose consensus is built before it's formally submitted as an RFC. But we could dig into that a bit more and turn RFC discussions into phases. e.g., Maybe when an RFC is first submitted, only high level architecture concerns should be addressed in feedback. Or perhaps maybe first there should be some agreement on whether the idea is even worth doing in the first place. (e.g., Is there some kind of vague consensus among the relevant team that they are on board with the idea in the first place?) Then each phase could get progressively more detailed and into the weeds.

There's a lot of potential problems with this sort of discussion though, particularly if there are inter-dependencies between the phases. e.g., Maybe there is a detail in the weeds that impacts whether it's even worth moving forward with an RFC? It's also problematic to enforce, since it would not only require a hefty time investment from someone moderating the comments, but also there's a lot of judgment required to balance whether a comment is out-of-bounds for a particular phase of the RFC review process. I think the unstated assumption of these types of guardrails is that it would be somewhat self-regulating. e.g., They are guidelines and not meant to be strictly enforced.

Anyway, apologies for being a bit rambly. But wanted to write down my thoughts. Thank you for starting this discussion!

10 Likes
3

It seems to me that the core premise behind the process and indeed the tooling used for it is wrong - that we need a discussion over some proposed description of the feature.

A better perspective is we need to have a collaborative brainstorming and authoring activity. Best achieved via a whiteboard. (E.g we use an online tool called Miro for that at $dayjob). Any discussions can happen in whatever informal way deemed best and only the results are captured in the board. This would replace the flood of comments on a pr with a list of distinct technical items, and also crucially how they all relate to each other.

1 Like
4

Apologies in advance for this being a bit longer.

I believe the issue roots in how the process is structured as well. One thing to remember is that while it is of course hard for the RFC author, it puts quite a burden on every participant in the process. The authors, the parts of the community agreeing, and those who have counterpoints as well. And this burden is not just felt on the Github discussions. It spreads to here, to the subreddit, to Twitter, and everywhere else discussions happen. This then also puts moderation on the spot where trying to slow things down a bit has the effect of taking a side in the discussion. All this creates a long-running circle of frustration with wide ripples.

But I do agree that Github issues are quite bad for these kinds of discussions. It lends itself to certain social dynamics that tend to amplify the bad parts. An RFC author can be overwhelmed by feedback, even supportive ones. Because the discussion might change direction, grow into other related topics, all the while trying to move the RFC into any number of certain directions. This dynamic is occuring in multiple RFCs right now.

On the other hand, from the view of the other participants it also has very draining mechanics. It's hard to be heard if you don't have some big impactful contribution, either in support or as a counterpoint. If you do put together some bigger argument with many parts, you face similar problems as the RFC author. There will be a number of people going on the offensive about your argument. And for each reply you'll get another set of new responses, partially repeating, maybe or maybe not disagreeing with each other as well.

Due to the mechanics in the first paragraph, when you do write a bigger, more nuanced argument, it puts a burden on the RFC author, making it quite hard to fruitfully engage with the whole of the argument presented. So parts will be missed or misunderstood. Which leads to cycles of back and forth that don't tend to go anywhere, since nobody has the breathing room to fully consider and engage.

So as soon as a certain number of participants, arguments or comments is reached, there isn't really much room for the group as a whole to find some kind of consensus.

Then there are the dynamics between the teams responsible for deciding RFCs and the community as a whole. It's not a good use of resources for busy team members to engage with RFCs early on, and they sometimes tend to only fully engage at the end of the process. This leads to a messy "race to a dominant argument" from all sides.

Additionally, there is a problem with precedents and general RFC history. It's extremely hard to find older arguments for a topic that comes up repeatedly. RFCs that come back now and again in some form or another tend to also repeat the same arguments. This is exceptionally draining on all sides of these arguments. It creates groups of people who are either on the offense or defense. The topic of "should this ever be a part of the language/library/etc" is an extremely exhausting one for all sides. It's certainly not fun for the author of the RFC.

Also additionally, the way RFC submissions work in general leads to an everyone-against-everyone situation. With the RFC author being in charge of the primary considered document, everyone is trying to fight for visibility of their ideas and concerns. There are also issues where certain things that an RFC decides are only considered after acceptance. This causes long-running post-hoc arguments in the community. This is not even considering how much happens after-the-fact in tracking issues that never flow back into the original RFC, making the whole process disjoint and hard to follow, as well as hard to predict for anyone participating.

Then there is the whole topic of general power dynamics when you have team members either being the authors of the RFC, or opposing them in the discussion.

I do think recent movements like the MCP approach are going into the right direction. I always thought a bit more formalisation of the process would go a long way. As a rough outline of what I think would be fruitful:

  • It should start out with a problem statement, devoid of a fixed solution, submitted to the relevant teams. The teams would consider the scope of the problem, if it even is one, what their concerns and constraints are for any solution, and so on. I haven't followed the MCP process too closely, but I think it is aiming for something like this. In my ideal world this would not end up with the submitted problem statement taken as-is. But with a new document outlining the problem space as seen from the teams themselves.

  • Solution RFCs would be in response to the above outlined problem RFCs. The big difference I would introduce here would be that instead of the author facing an indefinite amount of community members engaging, the responses would take the form of full documents as well. This would allow those opposing or wanting specific changes to organize as well, without immediately burdening the RFC authors. It also gives those with counterpoints breathing room to build up their argument.

  • A third hard part would be the mechanics of incrementing the solution incorporating the response documents until the relevant teams are satisfied with the outcome. Ideally, this would be done by a team member, as they have the ultimate say about what will happen. They would also be the optimal agents of making sure the problem space is well covered with the solution, and that all response documents were addressed in a constructive manner.

I think the main goal I'd be following is moving away from an everyone-against-everyone system where it's easy to see one side as a winner and the other as a loser. And move more towards a system where one-on-one interactions are either among document authors/supporters (for either the RFC or the response documents), or to get clarification and increase understanding between those groups. Ideally, everyone would focus their "big arguments" on making sure they are well expressed in the RFC and response documents, as those are the points that won't be missed by the evaluating teams or the opposing sides.

It would also make sure that there is a historic timeline of arguments for a specific topic, and that newer discussions can use these old ones. New RFCs could be attached to older problem-space definitions. Those problem-spaces would still have references to the old discussions that weren't accepted and can easily build upon them. Response documents could similarly refer to old discussions, and highlight old response documents that were missed in the new RFC. This would also allow an easier view of how the problem space changed over time. It would also counter the effect of topics going in circles until one side "gives up".

Really simply put: It's the technical topics that should be fighting each other, not the people. I do believe this does align at least a bit with how things are or were planned to evolve, but I don't follow closely enough these days to be sure how much.

6 Likes
5

One of the problems I've noticed is that it's unclear which feedback has been heard, and which changes will be incorporated in the RFC.

If there's a flaw in the proposed design, is it going to be fixed or slip through the cracks? If someone has proposed a clever new idea in comment number 37, is that going to be the new approach now or not? Has the RFC author decided it's a bad idea, or just didn't see that comment?

That lack of clarity where the discussion is means the same things are brought up multiple times, re-litigated multiple times, and it multiplies amount of feedback given without multiplying amount of new information given.

  • If I respond to the RFC text as it is in the pull request, I'm likely going to repeat things others have already said.

  • If I respond to the RFC comments, I don't know if I'm responding to an accepted design, or just random unbaked ideas (and it's probably the latter).

15 Likes
6

PRE-EDIT: I originally wrote this comment for the previous topic. Since then I removed all the links to specific RFC and discussions.

I never wrote an RFC, but I would like to share my experience in collaborating in an RFC. I'm not the author, I just commented a lot on those threads.

So, I recently participated in the latest attempt to get some feature in Rust (I don't think it matters, but I'm in favor of it). There is currently (ie. active discussions) a total of more that 200 comments in the RFC + the active threads on URLO. That's a lot, and we can't expect anyone to read all of them. I assume that most people participating read some, but not necessarily the latest one.

I feel that the initial reaction of the core team (I don't know all core teams members, so my judgement can be biased) was more or less « We don't have time for this, we have higher priority items (like GAT, specialization, const generics, …) to finalize before. Even though I would love to have some feature, I also agree that those items are even higher on my priority list. So I think we should try to be able, as a community, to iron any kind of low-priority RFC before using core members time.

In the various discussions, I feel that a few alternative solutions have not been correctly explored. It seems, and I think it's because of the huge amount of discussion around some feature, some people didn't took the time to read the RFC before commenting on github. Some extremely interesting remarks have also been made. But unfortunately, due to the linear nature of both IRLO and github, as well as the lack of tool to create effective sum-up, it is both:

  • really hard to progress (ie explore alternatives, answers the concerns about specific details, …)
  • and really hard to start to participate to those discussions (there is way to much to read, the useful information is too diluted).

I think that the tooling and the process needs to be changed and/or improved. I think it should be easy to:

  • get a sum-up with multiple details level (1mn read, 5 mn read, 10 mn read for example)
  • easily start a parallel discussion to experiment with alternative ideas (and it should be easy to get a sum-up of any of those experiment).
  • access the list of the current concerns, and their answers

Currently, the only real sum-up and authoritative source of information is the RFC itself, which is clearly insufficient.

2 Likes
7

I agree with essentially all of the prior post. Reading it, I wondered whether mind maps or concept maps might provide the basis for organizing such early-phase (i.e., pre-pre-RFC) discussions.

2 Likes
8

I like the mind-maps idea, here's my post I had drafted before you posted, but it's basically my train of thought arriving there. :slight_smile:

So my comments here are mostly about once a problem space has been deemed worthy of solution:

I think a huge part of this is the feedback as a raw stream instead of organized in any manner. Summary threads and the RFC itself help organize the outcome of the feedback, but not the feedback itself. And for a smaller RFC that's not controversial, that's still pretty manageable. But for big ones, it's definitely an issue.

How to fix that, I'm not sure. I think a lot of the feedback could fit into a tree / graph / other organizing structure pretty well, but there are definitely more nuanced arguments that might not lend themselves to be categorized so easily.

One option is just a threaded medium with heavy moderation (mostly for organization / moving comments) and a better threading model than Reddit. I think you'd want a model where the top level thing is a stream, but you can start thread for any comment, with the end goal of revising the comment content. And maybe adding a level or two of nesting beyond that just for organization's sake. In that sense, a GitHub repo per RFC (and with it the ability to use issues for individual points of feedback) is probably the closest approximation that we have without using lots of customization.

Another option, if we were to throw out constraints completely would be some sort of tool tailored to mapping out the problem space collaboratively in a graph format. I sort of imagine a mind-map where people can attach their comments to once they feel it's well represented.

1 Like
9

I also think that what make it so draining for the author of the RFC is that the person is the only one able to modify the RFC, and thus the one responsible to collect, sort and sum-up all the feedback.

I think that the creation of the RFC itself should be collaborative. Issues like grammar mistakes, or similar minor details could be patched directly instead of using the energy of the original author. Core members could add their personal issue to the list of known issues, and anyone could modify or clarify the RFC to answer them. Anyone could ask for more examples of where such RFC would improve the current situation and anyone could add examples to the list. Interaction with other RFC currently being worked-on could be explored in subsection. And so on…

Instead of being a back-and-forth battle it could be a much more collaborative effort. In addition, pools could be added to gauge the interest, or choose a given solution when multiple have been found with different trade-off, …

Of course people from the lang-team would have the last word, but it should make the process much less draining for the original author of the RFC, while allowing faster and less time-consuming feedback loop for the lang-team (by simply adding an issue to the list of unsolved issues).

I think there is something to explore here. I more or less came to the same conclusion.

EDIT: I just realized that such tool would be extremely valuable for any kind of exploratory discussion, for example the ongoing question of « Do we need a 2021 edition, if yes what do we include, if no what is the cost of not doing one ». It would allow a better visibility of the current status both for the people being active in the discussion, or external people just wanting to know what is currently being agreed on.

2 Likes
10

Ahead things first: I was part of the conservation and asked the question, that led to the critical points and clarification with disappointment. Sorry withoutboats, if I did things wrong to you.

  1. Specifically related RFC/how to reach to people with knowledge Part of the specific problem that this thread is related to was the absence of good comprehensive documentation, that the RFC was partially based on. I am not sure what one can do about that except requiring or asking for feedback on the (very) early design phase of the RFC for people with according knowledge. (how does one reach them?) (The other part would be requiring things being broadly described in some manuals. see 3.)

  2. Missing documentation Sporadicly RFCs are based on behavior, that is not yet documented in manuals like the book reference no-std or nomicon. I am not sure on a guideline where general behavior is required to be documented, which is not very helpful and I think this is overall a problem of the project size.

  3. Efficient lookup of information Lowering the bar regarding lookup by explicitly writing the prequesitory information prevents such disappointments. I think overall how stuff works should be described in a collection of one of those books and they should be explicitly linked as head of issues or in the template for RFCs and preRFCs.

  4. Controlling group dynamics Aside of that, I think authors should be able (after a limit of participants) to move the discussion, for where the participants may choose a limited amount of coordinators (for a limited amount of time), so the discussion burst settles down. This may delay the process for a long time, but I think this would be acceptable.

  5. Noisy internals forum Even the internals discussion or preRFC become fast too noisy, why initially I did not want to take part on this forum.

  6. Sorting RFCs + special announcements Having some keywords for the area of interest for pre-RFCs for RSS + mailing lists on the directly linked on the main page of rust-lang could help. This would require sorting the (pre-)RFCs into some categories.

If you are interested, I would be interested in designing something.

11

My 2c:

  1. Start out by expressing sympathy for the RFC author's intentions, regardless of how bad their approach is.
  2. Stop the passive-aggressive tone towards the RFC author's approach: "you didn't specify what syntax X is supposed to mean", "as it stands, this RFC requires quite a bit more work", "I'm disappointed to see a possibly-good idea not taking off because the author didn't bother to convey it well" etc. I think some members of the community should learn that (1) their unwarranted negative feelings should be their own problem and no one else's, (2) anyone can point a finger at a problem, but very few can constructively come up with a solution as well, and (3) not everyone is an expert in presenting an idea, so there's no need to show hostility to them just because they're inexperienced. We've all been newbies at some point.
  3. Have a highly visible list of topics that have already been discussed to death, to avoid embarassing would-be authors with the good-old "proposed before, rejected before" response (e.g. named arguments, a proposal that just won't stop cropping up). Maybe display a highly visible warning when the poster starts typing "RFC" in the title, possibly linking to a How-to guide as well.
3 Likes
12

I'm going to go against the current here and share my perspective: as someone who recently pushed a RFC and took part in a few RFC discussions, I don't think the process is really flawed. In fact, I think some of the adversity is desirable, and being able to withstand it is a requirement for changing the language.

Disclaimer: I'm know a lot of the arguments I'm using are very similar to arguments that have been used in other communities (Linux, systemd) to justify toxic behaviors and petty insults (eg "I can't believe someone could possibly be dumb enough to suggest this", stuff like that). To be clear, I'm not saying toxicity is a desirable part of the process, and I'm very happy that Rust has a mostly non-toxic community.

The thing is, the RFC process is by nature a filter. We can try to shift the "load" to a different platform if we want, and mandate pre-RFCs, MCPs, etc, but the bottom line remains the same: there are a lot of people with ideas of how the language should be changed, and few lang team members. More importantly, everyone thinks they're a language designer (I've certainly been guilty of that); everyone has ideas on where a language should go next, and most of these ideas are terrible or contradict each other; so we need a filter to keep only the non-terrible ideas for discussion; asking people to work on their ideas and be ready to defend them is part of that filter.

To speak of my own experience when I published the placement-by-return RFC, yes, the wave of criticism and negativity was a little daunting throughout. In some cases I thought the feedback was just splitting hairs; in some cases I was annoyed that people were completely focusing on a part of the proposal that I considered secondary (and was filed in "future possibilities"). Very few of the changes I made helped me understand the core proposal better, or changed my mind on what it should be.

But these changes I made in response to feedback helped other people understand the proposal better. It helped me understand what other people considered strong points, and understand which abstracts concepts needed to be re-thought on a language level to better integrate the proposal (eg I have a different idea of Result now).

My point is, there was no way to make these changes painlessly. Even if everyone posting feedback had been more polite, showered me with praise and made sure to never repeat the same comment twice, there would still have been conflicts between how these people saw the RFC and how I did, and resolving these conflicts is where the hard work is.

tl;dr I don't think the RFC process needs to be fundamentally changed. Overall people are mostly polite and offer constructive feedback; sometimes that feedback is negative, but that's the game. Addressing negative feedback is how you show that you've put in the work.

As an aside, I find my MCP experience, posting a short idea and then getting nothing but silence for weeks, much more discouraging than any amount of negative feedback.

Though realistically, "the lang team doesn't have time for this" is valid feedback, and the only one you actually need.

20 Likes
13

Thanks for bringing this up! It is true that authoring an RFC can be demotivating; it was in my case. Even though I invested a lot of time writing the RFC and discussing it on IRLO, I got a lot of negative feedback on GitHub. I'm not sure to what extent that was my fault. Maybe I could have moderated the GitHub thread better. Maybe my RFC is just a bad idea.

I've read this concern many times, but most people who use this argument aren't actually part of the lang team. If the lang team doesn't have time for an RFC, they should say so. I'm fine with my RFC being postponed if they have more pressing matters to deal with, but I don't think it's a valid argument when coming from someone who isn't part of the lang team.

4 Likes
14

I wholeheartedly agree that GitHub UI is unsuitable for RFC discussions:

  • Comments aren't loaded when there are many. Which may lead to non-searchable.
  • There are no automatic / easy way to summary the discussion.
2 Likes
15

Since RFC's are given in terms of a document checked in to Git, why not make all feedback required to take the form of a PR against that document with the desired changes as well as an explanation for why the changes are needed/pertinent. The author of an RFC should be permitted, and in fact encouraged, to reject any PR against the RFC that doesn't provide justification or engages in personal attacks or that is simply a duplicate of another PR, etc. Also, any PR that has unrelated changes should be rejected and required to be split into separate PR's by the PR author. Ideally, comments would be disabled on the RFC PR itself with a prominent notice directing that all feedback must be a PR against the RFC document. If it isn't possible to disable comments just for the RFC document and PR, then notice should be given that comments on the same will be ignored/unanswered by the RFC author, as dictated by the official Rust RFC process, and that all feedback must be in the form of a PR against the RFC document.

A side, but important, benefit of this is that it requires a little more of a commitment on the part of those who have legitimate criticism of an RFC. It also allows and encourages forking for alternate forms of the RFC that diverge greatly from the original to provide a rallying point for those with a different view on it. It allows those who support a particular change already proposed to upvote that PR and comment just on that PR which better keeps related feedback together in one point and allows the RFC author to deal with N issues with M comments each rather than MxN comments in a single comment thread with unclear lineage as to root issue being addressed.

It also makes it easier for the author to incorporate accepted changes into the RFC by simply approving and merging the PR once it has been discussed and accepted. In addition, the RFC author can provide focused feedback and ask for clarification etc. in the comments of a given PR which also keeps that much more focused as well.

Because it is PR's, it will be easier to see conflicting PR's, and a PR without a clean merge can be rejected back to the PR author so they can refine it against the current document. As a result, an RFC author can focus on the highest upvoted PR's first and/or the PR's that the author feels have the best motivation and add best to the overall RFC, get them accepted and merged, and the reject (ideally auto-reject) any PR's that remain which now have merge conflicts. This makes the work of competing changes much less for the RFC author.

NOTE: reliance on merge conflicts alone is not enough. There can still be conflicting proposed changes that don't cause merge conflicts and those that cause merge conflicts may not be actual conflicts in purpose, just conflicts in wording. Nevertheless, filtering for actual merge conflicts reduces the burden on the RFC author and better distributes the work of sorting out conflicting proposals to the proposers themselves.

All of this should take a lot of work off the RFC author, focus discussion better, and require more commitment and effort on those wanting to criticize an RFC to actually take the time to construct a well thought out solution to their concerns and to act as a champion for their suggested changes or improvements. It also discourages "Drive By" comments on the RFC that require low-effort on the part of the commenter and adds little to the signal while adding greatly to the noise.

NOTE: You can still have somewhat "Drive By" comments on PR's to the RFC's, but those are now much more focused on a particular change, much less burden for the RFC author and instead more of a burden for the PR to the RFC author, and make less "Noise" in the overall process while doing much less to diminish the "Signal".

I believe proceeding like this would make the RFC process much more collaborative and much less adversarial. It would also naturally distribute the work of refining an RFC between the original RFC author and those wishing to modify, enhance, correct, or deny the RFC.

For this last point, denial of the RFC outright because the thing being proposed runs counter to Rust's core purpose and philosophy, the feedback can (and perhaps should) be in the form of a forked negative RFC that proposes that the original RFC, or any like it, no matter the corrections or modifications, should never be accepted into Rust. Acceptance of the negative RFC by the language/compiler teams should result in immediate denial of the original RFC. Any future RFC's for the same thing should be denied by the language/compiler teams on the basis of the previously accepted negative RFC, unless an RFC is proposed and accepted to retract the negative RFC based on new information or circumstances that makes the blanket denial no longer applicable. This should have a high bar and the default position should be to deny such an RFC without an airtight justification.

TL;DR

  • Disallow comments on RFC PR's or the original RFC
  • Feedback for changes must be in the form of PR's against the RFC document that contain justification for the change
  • Mod PR's can be upvoted/downvoted and commented on, thus naturally grouping feedback under specific issues rather than mixing all feedback together into an unmanageable uber-thread
  • Competing alternatives that differ wildly from the original can be forks of the original that follow the same process and provide a rallying point for alternative proposals that still link to the original
  • Naturally distributes and compartmentalizes the work of modifying and refining an RFC between the original author and those seeking changes in a much more equitable and manageable fashion.
  • Doesn't require changing the process that much or using new infrastructure.
6 Likes
17

Via a negative RFC. Alternatively, they could propose a PR which is effectively: Add the following to the top of this RFC, "This RFC is being rejected because of ....," acceptance of that is the RFC author admitting that based on the criticisms, feedback, etc. the RFC should be rejected. This means the language/compiler team would then automatically reject the PR for the RFC from being accepted into the Rust repo.

18

I think that the pre-RFC process itself should be more collaborative. It's especially important when different design are being explored in parallel. I don't think that multiple PR would make it easy to have an easy overview of what is being worked on.

Let's take a look at what should be in an RFC. When multiple solutions are explored in parallel, a good chuck is common to all possible solutions (the name, the motivation, the rationale, the open questions, the drawback, prior art, …).

I propose that a document with the following structure would be created instead of the current RFC process.

<Feature name>

Summary, motivation and rationale

This feature would allow the following use-cases:

  • <use-case 1>
  • <use-case 2>

Those use-cases are not currently covered properly because <reasons>.

Open-questions

  • <question 1>
  • <question 2>
  • <question 3>

Drawback

Introducing any form of <feature> would have <impact>

Prior Art

<feature> have already been explored in <link to other implementation possibly in other programming language>

Proposition A

Summary

<Feature> would be implemented in <short explanation>.

Guide-level explanation

The use-cases would be implemented as such:

  • <use-case 1>
  • <use-case 2>

Additionally <use-case 3.a> is also covered.

Answers to open-questions

  • <question 1>: <answer 1>
  • <question 2> : <answer 2>
  • As detailed above, <question 3> is out-of scope for this proposition.

Reference-level explanation

<implementation defined!>

Drawbacks

The proposition A have specific drawbacks:

  • <drawback A.1>
  • <drawback A.2>

Proposition B

<same structure than proposition A>

I think that such document should be created in a collaborative manner, in a wiki-like format. This would make it much easier to develop each solution independently, as well as making trivial changes (like grammar) much easier. If griefing is an issue, maybe having a given rank on irlo could be needed to be able to edit some/any section of the document.

Using such structure would make it better in my opinion for the following reason:

  • it's easy to have a global overview, as well as an overview of each proposition (especially if the subsections are foldable).
  • it's easy to check if all open questions have been asked (ie. does <feature> works in <specific corner> case) by looking at the list of of open-question (in the "open-questions" section) and the way they are answered for each proposition (in their respective "answer to open-questions" section).
  • missing details could be easily spotted if things can be tagged in the same way than missing references in Wikipedia.
  • it's easy to compare the respective approach of each propositions, their forces, weakness and the maturity of any proposition compared to the others.

~

  • As a member of the lang-team, if you think the proposition isn't ready, you can easily add a question to the list of open-question, and not waste time by reading the entire page, then come back later when someone has answered it.
  • As the author of a proposition, you can check that a proposition is ready by checking that all the open-question are correctly answered
  • As a contributor, you can help by contributing to the various section of the document

And finally when the draft is mature enough, it should be extremely easy to extract a proper RFC, with all the rationales, drawbacks, and other implementation correctly detailed. The RFC itself would just be a re-ordering of the various sections.

What do you think of such idea?

1 Like
19

I think your ideas are overall usable, but may not work on more complex situations and group dynamics (people can still spam PRs or do this in a controlled way).

  1. For simple changes this would work, but probably not on conflicting ideas in the same RFC, where the dependency is more complex and affects multiple parts and could hide the fundamental disagreement.

  2. How does this model questions regarding subparts of the RFC, when the semantic/intent is unclear to the reader?

  3. Please no wild forking of RFCs, but a process on doing that like something I proposed. Conflicts need to be settled in a civilized manner (at best at one place with somewhat limited time) and should not waste the time of the team and other people.

1 Like
20

Do you know a specific wiki that can do this (specifically semi-automatic folding of fixed questions)?

The burst-control then should be more of a guideline-issue (and how to find people, who summarize the shortcomings/questions).

Meta: Is there a plan when to summarize the discussion?

21

The mobile version of wikipedia makes it really easy to fold top-level section. I don't know if it's enough. Unfortunately my knowledge of wiki engine and similar tools is really limited. I think that being able to use markdown would be preferable (mostly to be able to generate RFC easily). Fortunately it seems that such plugins. But once again, my only contact with wiki engines is as a (really small) Wikipedia contributor.

The kind of process I'm proposing would try to solve exactly this! And I agree that a summary is needed.