(How) can we do better as a community?

community
1

A few days ago, lang team member @withoutboats posted a RFC about adding async destructors. I do not want to discuss the technical contents of this RFC here, but rather ask a question about the discussions around it.

The PR of this RFC quickly accumulated lots of comments listing technical concerns. I perceive almost all individual comments as largely constructive. (Disclosure: I wrote three of the comments.) Some pointed out edge cases or similar concerns. Some expressed disagreement about the core trade-offs proposed. A few were off-topic and about the commenters' general qualms with Rust's Drop mechanics, but from my impression, that was the most problematic thing there was.

However, although each individual comment was civil, I can understand boats being overwhelmed and put off by the whole of them. Today they closed the RFC with the comment:

i dont want to deal with this rfc thread. im not getting paid to do this and it makes me very unhappy

They also tweeted:

Great thing about not getting paid to work on rust is I can just close my RFC instead of engaging in the awful back and forth

Of course the rust project might want to do something about having processes that make me prefer to walk away than contribute! I know people are trying to fix things but seriously

withoutboats has been contributing great work to the Rust language, ecosystem, and community. A situation which makes them, or any other contributor, feel unhappy about contributing is a situation we should strive to avoid. While I sympathize with the problem, I think that in this case, the solution is not simple at all.

My comments to that thread were my first contribution to rust-lang/rfcs, and it isn't fun to realize you might be part of a problematic dynamic. I was contemplating how to learn from this and handle this better in the future, but I couldn't really find an answer.

So, my questions are:

  • Is the way this PR thread played out problematic and something we should avoid in the future?
  • Were the comments made at an appropriate time in the development in the PR? Was it ready for comments from the wider public? If not, how can we communicate this timing better?
  • Was the tone and attitude of the comments appropriate? If there is room for improvement, how can commenters strike a tone that is more beneficial to the Rust community and its culture of public collaboration?
  • What "volume" of feedback to a RFC is appropriate and sustainable? If this differs between RFCs, how can we communicate this level better on a per-RFC basis? How can specifically the commenters to an RFC (assuming the best of their intentions) control this volume while making sure every concern is eventually voiced?
  • Are there any other steps we can take or behaviors we can encourage to avoid these problems in the future?

Some notes:

  • So far, everyone involved seems to have managed not to blame each other. I'd like to keep it that way. (Special kudos to @withoutboats - being on the receiving end of an unhealthy dynamic must make this quite hard.)
  • I posted this to internals because the motivating incident occurred in the Rust development community.
  • My questions are not directed specifically to withoutboats, but rather to all of the community. I expect there will be disagreement about the answers, but we don't necessarily have to agree in order to collect helpful suggestions. Please be civil.
  • 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.
12 Likes
2

(Note: I'm responding in regard to RFC threads in general; I haven't read that specific thread, and nothing in this comment should be interpreted as commentary on either this RFC or any particular interaction in that thread. I've seen similar things play out in other RFC threads.)

At the point at which something has appeared as a full RFC, it's critical that any remaining potential issues or discussion points with the RFC be raised. (They ought to be raised in priority order, as it's annoying to deal with architectural concerns and a pile of typos simultaneously, but that doesn't mean they shouldn't be raised.)

I do absolutely think that GitHub is a poor discussion medium, for a variety of reasons. No threading, limited ability to mark feedback as "done" (only for line-level comments, not top-level comments), very much a wall of undifferentiated

I also think that we need good processes for structuring feedback, so that it's possible to do a little work, get some high-level conceptual feedback, sketch out an architecture, get architectural feedback, fill in the details, get detailed feedback. We should not set up processes that require writing full proposal documents and then potentially receiving conceptual or architectural feedback.

Our current approach, of having only informal discussions on places like Discourse and then posting a complete RFC, is not an especially friendly process, and seems much more likely to produce this "wall of feedback" effect.

The MCP processes and project groups are supposed to help with this, though they're not a panacea.

One thing MCPs and project groups can potentially help with is giving a time and place for architectural feedback, and trying to make it so that by the time an RFC is posted, it's highly unlikely that there will be any major architectural concern. People can iterate on an idea within the project group, nail down the concept, then the architecture, and much of the details, and by the time an RFC is posted, most of the time the feedback would be at the level of "this needs better phrasing" or perhaps "there's an interesting interaction with this one language feature that you might not have considered". That will hopefully reduce the "giant wall of feedback" effect.

3 Likes
3

You can't evolve an argument on Github. One thing I catch myself doing (far too often), and which is not helpful for a technical discussion, is making a comment to an issue, PR, or in this case RFC and, being done with the main argument, hitting send and realizing a few minutes later that I left out an evaluation of counter points, didn't choose a clear example, etc. This is really unhelpful because updating the text is confusing to everyone involved and only causes a larger split of the discussion. The only way to fix it properly would be to add even more text as most wouldn't read the update otherwise.This causes any medium sized thread to quickly devolved into a discussion that just can't be followed.

Three points contribute to this:

  • My own style of thought for which I'm responsible. Sometimes this is an advantage since the How of arriving at a particular conclusion hints at points which deserve a better explanation. But mostly, it's a way to debug my own thoughts and examine if there are any unclear leaps of logic, which leads to hard to understand text.
  • I think this is reinforced by Github's UI and UX though. Particularly I experience that sharp contrast right now. For once there is no 'save' button for comments on Github so I'd have to rely on the browser. And then everything down to the exact Markup support (of referring to issues, parts of code, other comments) is centralized to Github which complicates offline editting in the first place.
  • Comment threads are linear. This has been mentioned a lot before so I'll not go into details.

The lack of a summary is a clear consequence of all of the above. I think a better consensus platform would promote iterating and updating comments to incorporate pros and cons over expanding in new discussions.

4

Also: while we need to have discussions about the RFC process and feedback processes in general, using any one RFC as an example could create a potentially unwanted focus in such a discussion. Threads like this can draw a great deal of attention and require a lot of energy to deal with.

Did you check with @withoutboats before posting this thread, to see if they would want this RFC to be the catalyst of such a meta-discussion? If not, I would propose that we close this thread and start a separate discussion not centered on any one RFC.

3 Likes
5

I can't comment on @withoutboats's perspective. Instead, I'll share my own: Writing an RFC isn't fun. The back-and-forth on an RFC thread is even less fun. Even if the conversation is 100% positive and constructive, it's just not enjoyable to me. I'd rather spend my precious free time doing something else.

I think it's great you're asking these questions, @binomial0, but I'd like to follow up with:

  • How can we make the RFC process less draining overall?

My initial thoughts on some steps in the right direction include:

  • Embracing the MCP process.
  • Banning MCP/RFC discussions from GitHub. GitHub is a terrible forum, IMO. At my $dayjob we use Google Docs with comments to do our designing+discussing. It's not perfect, but it's infinitely better than GitHub. There are other alternatives too; I'm not saying we should move to Google Docs. I'm just saying we should move away from GitHub.
  • When an MCP/RFC is posted, linking to all the discussions that have occurred in the past. So much time is spent rehashing the same points. If people could discover past discussions more easily I think it would help. (side note: these discussions need to be easily searchable; GitHub and even Discourse have pretty terrible search and discovery).
6

This thread feels like a not entirely evitable consequence of my choice to vent on twitter, though I don't really want to engage it very much. Sorry for causing a scene.

Fundamentally the problem from my perspective is that the RFC process easily becomes adversarial, and that the author of the RFC has sole responsibility for one side of this "debate" against many. It feels like defending a dissertation, but against anyone who wants to come by. Some comments (including some comments on this RFC) feel collaborative, raise issues the author hadn't considered in a way that feels positive and constructive, etc, but often times that is not the case.

This RFC I wrote in November 2019, and have been meaning to share for a long time, mainly so that someone else could take it over. I'm not very invested in its outcome. So when it became something that made me feel upset, I just closed it. Other people can open a follow up RFC.

I don't want to single out the commenter who made me upset because the feeling I had is my universal experience with writing RFCs for Rust. There is always this adversarial experience, in which I feel also condescended and disrespected. I think this is in part because of the process that's been implemented, but also because of the project and community culture and the expectations that team members have set in community members.

I believe that new processes like MCPs will make things better, but it will be slow.

11 Likes
7

I did not, and I'm sorry for risking creating another unhelpful discussion. I wouldn't have done this to a still-open RFC, but because it is closed, I thought that the risk was low. I still should have checked with them, sorry.

I think having a concrete example makes the problem easier to understand. However, preventing toxic discussions is more important. I don't feel able to decide if closing this topic is necessary, because I'm not the one to bear the potential bad consequences and I don't have experience in moderation. I'd like to leave that decision to you and potentially withoutboats.

If this thread is closed for this reason, I'd like to rewrite some of the questions in a way that doesn't mention a particular discussion and post them on a new thread.

1 Like
8

I think it would be appropriate to close the thread before it gets too many posts, and post a new thread (not linking to the old one), making all the same points but not calling out any one RFC discussion.

3 Likes
9

Then let's ask the moderators to close this. I think I'll flag my own post, this should hopefully get their attention.

Edit: Created new topic at https://internals[dot]rust-lang[dot]org/t/how-can-we-as-a-community-make-the-rfc-process-less-draining/12780 - linking from here to there should be unproblematic, it's the other way that would defeat the point.
Edit: I really like the points that were made in this thread, and I'd like to encourage y'all to repost your statements to the new thread if you want. I won't outright repost other people's statements, but I think they would fit there.
Edit 2: Well, linking this way is not unproblematic. Thanks, discourse, for showing reverse links. I hope breaking the link fixes it. Sorry. Edit 3: Breaking the link here worked.

4 Likes