[blog] Rust Governance: Scaling Empathy

#10

You’ve been reading about Discourse’s fourth trust level, haven’t you? I should warn you that there are known weaknesses in its approach.

  • One of the obvious ones is that a TL4 user can’t break a mega-post in half. The only way I know of is for a moderator to edit the off-topic chunk out, make a new post elsewhere, and reassign the post to the OP. And only moderators can do that.

  • The other big downside, inherent in any curated approach, is a feeling of lost autonomy. Kind of unavoidable, since giving you power is synonymous with giving you a system that you can game, but feelings of powerlessness are exactly one of the things you said you wanted to fix.

  • Taxonomies are not neutral. This includes whatever rationale the leader in question uses to decide if something is on-topic.

In spite of the fact that I think this is better than Reddit’s approach (notice that I have TL4 on here, while my Reddit account lies deleted and burned), it’s not going to completely fix the growing sense that individuals don’t have the ability to shape rust’s direction any more. Because they don’t. And any process, even a manual one, is going to be dominated by whoever puts in the most time to deal with it.

#11

I don’t think either a social solution or a technical solution is sufficient on it’s own; both are necessary.

I think the key here is that just creating more threads doesn’t help if those threads also become unproductive; you’ve just created more noise. Rather I observe that the most productive side-conversations I have seen are two people discussing one-on-one somewhere else in good faith and coming back. This suggests the following properties:

  • The discussion should not be visible to others by default. It should be out-of-band, but linkable.
  • The discussions should have a fixed and well-defined purpose: they should be spawned to discuss some particular comment or view point, rather than the whole proposal in general. Once that discussion is done, the thread is done.
  • The discussions should be strictly invitation-only. The creator of the thread should invite one or two select individuals to discuss. It is strongly discouraged for anyone else to join the conversation.
  • Once the thread is over, the conclusions drawn from it are posted back at the main thread.

Assuming we agreed on the above (bare with me), none of the existing forums really seem to meet these criteria currently. It seems to me that the github might be the closest, but I think we would still need some automation to make it work.

#12

Oh, no, this is something I’ve been talking about for at least two years now.

but feelings of powerlessness are exactly one of the things you said you wanted to fix.

Having nonpartisan entities do the actual curation really helps with this.

one of the things I suggest in the post is precisely this: the facilitator proactively encourages people to have a discussion elsewhere (perhaps creating a space for them, e.g. a github issue), and links it back. Technical tools can help make this nicer (especially for moving existing comments) but this is already doable with the tools we have. Whether or not this discussion is invite only depends on the situation, for involved discussions on specific points it makes sense for this to be an open forum (just elsewhere), whereas for individual disagreements encouraging people to use private chat seems enough.

#13

One thing that is (to me) conspicuously absent from all of these blog posts I’ve read on Rust governance is any statement that large spike in discussion on proposals and RFCs is resulting in better outcomes. In fact, it seems that there is a near unanimous view that outcomes are unchanged or worse degraded by these endless debates. If this is the case, then it would seem to follow that it would be better if the vast majority of posts in contentious threads were never made.

#14

I agree with that, but I’d like to express it with a little more nuance.

Most comments in high-volume RFCs don’t add much new - they’re likely either contentious or not saying anything new. Those are the comment we want to less of. And we have two main ways of reducing that flow:

  1. Resolve the motivation for posting (e.g. in this thread we talk about resolving conflict offline, ergo reducing conflict and contentious comments). People who would have commented in this scenario but didn’t are satisfied.
  2. Placing barriers to commenting. Could be an artificial comment cap, locking the discussion to certain people, or holding the bulk of the conversation elsewhere and only posting the conclusion, not the arguments that lead to it, etc. People who would have commented in this scenario but didn’t are not satisfied.

I don’t think you were endorsing #2 (or that anybody in this thread did), but I just wanted to note that in addition to aiming for less comments made, we want to make sure to aim for less comments made because the people who didn’t comment feel like their potential comment has been addressed.

And I think this thread has a lot of good suggestions and considerations made in that regard.

#15

FWIW, I think some form of #2 is inevitable if we really want design discussions to scale. Maybe we don’t quite need it yet, and we should certainly try all “type-1” solutions first so we keep type-2 solutions/barriers to a minimum, but I can’t see us never needing a barrier of some kind. But I don’t think that barriers to commenting necessarily mean leaving people unsatisfied.

The key thing is to distinguish between “comments” that everyone is effectively required to read before participating in the discussion at all, and “comments” that are optional to read or respond to. I think we can all agree that there should always be an official place (covered by the CoC, team members watching, etc) where anyone can comment on any RFC with no barrier other than the ability to write English. But we don’t need to make all of those comments automatically go in the “you must read this before commenting” pile the way github RFC threads implicitly do today.

For example (this is a strawman just to make my thoughts concrete enough to avoid misunderstanding the general idea, don’t worry about the details), we could lock comments on the github RFC pull request thread to just team members and facilitators because it’s their job to summarize discussion and ultimately accept/reject the RFC. Then have this or some other Discourse instance be the official place where anyone can post opinions, comments or questions related to the RFC, including disagreeing with past summaries, and it’d naturally be just as well-threaded as irlo is today (which is to say, not perfectly, but still asymptotically better than smushing everyone into one thread).

In addition to the many obvious threading benefits that every suggestion here hopes for, I like to think something like this would lead to more people participating, not less, because you no longer have to worry about your comment or question potentially wasting everyone’s time (it’d certainly have that effect on me), and you’d have far fewer “mandatory comments” to read before participating.

#16

I like that idea a lot actually. Specifically, I like the idea of having a continuous stream (where anybody can participate) vs an ongoing summary.

I had an idea similar to yours, but instead of two locations, the summary is inline at the top - a moderator asks people to edit/delete their comment saying that it’s been summarized in the first comment, after said moderate has made sure that is in fact summarized up there.

But I really like the two separate locations you suggested because it’d be easy to a) keep the github RFC clean and official status update and b) still allow people to add there two cents (in the irlo). I actually really like it.

I know you said it was a strawman, but I really the direction it’s going. You could go so far as to ask people to strike through their comments on irlo if they feel like it’s been well addressed/summarized in the github RFC. Thinking more, the downside is that it requires all people who previously have participated in github discussions to now also have a irlo account (not a huge barrier, but still a barrier). For sake of ux continuity, we could have both threads as separate github issues.

I’d have to think more about the downsides of two separate locations, but I really like that idea for things that are going to be huge.

#17

Part of the reason I threw out that particular github + irlo strawman is to show that I do not believe we need to invent any brand new discussion management software or convince existing platforms to make major changes in order to solve these problems. I don’t think anyone’s explicitly said that, but a lot of speculative comments on this subject seem to drift in that direction, which lends to a sense of “this would be nice but obviously won’t ever happen” that I’ve been feeling in some of these threads.

I don’t think I have any strong preference about what the two “locations” should ideally be. Having some kind of special summary thing at the top of a github discussion thread would be cool, but obviously that falls under “convince existing platforms to make major changes”. But we could get awfully close even with current tech, by repurposing the initial PR comment as such a summary, and giving team members/facilitators the admin powers to edit that comment for that purpose. However, having “both locations” be on github makes it a lot harder to make proper threading a reality, so we might want a separate forum anyway.

#18

The two-thread solution is a form of gatekeeping. Basically every common criticism of gatekeeping will, thus, apply. The summary will be seen as propaganda, especially since the gatekeepers and the decision makers are part of the same organization. It also still requires someone in the gatekeeper class to read all of the public thread.

#19

I do feel like that’s mostly mitigated by having people in the free-flowing area striking out their post as soon as they feel like it’s been addressed in the summary (ergo you can look at the freeflow thread to easily see what hasn’t been summarized well). But you are right, it’ll still lead to contention is my guess.

Also, sorry for derailing this thread - it was mostly about the article and then I led us off into a tangent about categorizing ways to reduce comments… worth discussing, but maybe not here.

#20

I might be wrong, but I think this is the right place for it because the post is about scaling empathy, and the volume of comments (especially unhelpful ones) makes it far harder to scale.

I also kind of liked the strawman, but I think the primary danger is that the second thread (e.g. irlo) becomes the unproductive thread because anyone can post there. Effectively, the barrier for posting junk in that thread becomes even lower, except now some poor facilitator must read it.

I do really like this observation, though:

#21

I’m a bit worried about equating organizational empathy with decreasing the number of people represented in processes. It doesn’t necessarily equate to number of perspectives lost but it’s not too far removed. Further, IMO if we add tiers of participation we should do so in a way that is prepared for the iteration needed for participation to grow 10x in the coming years. I don’t think that incrementally closing the process off is in the spirit of our community, nor will it ensure the needs of everyone are represented as the mix of community participants changes to include more representatives of “socioeconomic power” (companies, governments, etc) over time. To put it a bit strongly, I’m convinced that we need to find actions we can take to stay as open a community as possible while also succeeding to grow the community and overall adoption.

Another way to put this is that we cannot put the genie back in the bottle. Sharding decision processes only works when there is good coordination and stakeholders feel adequately represented. If possible we should be discussing how to give ourselves tools for ensuring good coordination and representation (“empathy”) rather than ways to keep our discussions small.

This forum is also subject to some selection bias - irlo is generally a place for those who perceive themselves as contributors in some way already. Would additional layers of threading help us maintain access to the perspectives of new users of the language as we grow and the language changes? How will a more closed process hear about the needs of people who have not previously been in scope for our marketing, like first year CS students?

This post is rambling quite badly right now, but there’s another question I’d offer: “how can we avoid pulling the ladder up after ourselves on rusts process inclusiveness?”

#22

OK, I can see your point on how this is the place. In my mind, after reading the article, my internal framing was “We need to scale empathy, and here’s a one way to do it”, and I had scoped the thread to the one way to do it, not the motivation itself. And I had been thinking of the facilitator for contention as being orthogonal to (or at least able to be implemented first independent of) a facilitator that helps people be (and feel) acknowledged. But you make a good point about them being intertwined.

#23

Ideally we’d able to keep them represented without needing a unique comment per person involved. I.e. we the motivation for not commenting to be because they feel like their potential input has already been adequately addressed. I think if we can keep that in mind, we’ll end up with good solutions, at least from a community side.

#24

To add to this, the solution to the scaling problem of n-to-n discussions growing out of hand is not to reduce n (that’s temporary), it’s to linearize them.

#25

I mean, that’s part of my original proposal, isn’t it? If there are decent summary comments and other such attempts to linearize the conversation, this isn’t really necessary.

#26

I’m not arguing for closing off the discussions. I’m arguing for raising the bar and also making it easier for individuals to have constructive discussions. I think getting rid of the noise is necessary. I think these are the same goals you and @Manishearth are also arguing for, right?

#27

Yup. I only brought it up because as stuff gets rehashed it gets lost easily.

#28

I consider the noise to be a symptom; a policy that directly cuts the noise out is treating a symptom not the problem.

So yes, I am advocating for getting rid of the noise, but not directly, rather by introducing systemic changes that make the noise no longer necessary.

You say that “the volume of comments (especially unhelpful ones) makes it far harder to scale” – I’m arguing that scaling involves a holistic solution that makes these comments unnecessary – you’ve got cause and effect mixed up.

#29

Another way to reduce the number of comments on excessively long threads might be to just ask people to comment less, say with a sticky post on popular threads. I think a lot of commenters don’t feel very strongly about a given RFC, but just want to help out and if ask would dial back if asked