Hacker News new | past | comments | ask | show | jobs | submit login
Rust Moderation Team Resigns (github.com/rust-lang)
914 points by hasheddan 8 days ago | hide | past | favorite | 834 comments





There are two statements here regarding things that have happened:

> the Core Team placing themselves unaccountable to anyone but themselves

> we have been unable to enforce the Rust Code of Conduct to the standards the community expects of us and to the standards we hold ourselves to

It's possible that there were CoC violations that they were not able to moderate, that the actions available to them were limited (e.g., they would have initiated a ban but they were not able to ban a core team member), that a core team member intervened to prevent effective moderation, or that the core team prevented the mod team from being able to access official core team channels in order to moderate.

Seems to be a wide variety of possibilities and leaving the nature of the situation ambiguous* will likely make it difficult for a new mod team. I hope the now-former mod team are open and direct with new or potential mod team members about the environment they're entering.

* I do think it's right for the mod team to not reveal the specifics in public; that would likely provoke targeted harassment and make the situation much worse


> It's possible that there were CoC violations that they were not able to moderate, that the actions available to them were limited (e.g., they would have initiated a ban but they were not able to ban a core team member), that a core team member intervened to prevent effective moderation, or that the core team prevented the mod team from being able to access official core team channels in order to moderate.

It's not clear to me that they're claiming a violation occurred.

The wording is vague, but one interpretation is that they simply wanted more control over the core team but the core team didn't want it structured that way, so the mod team resigned.

IMO, it would be strange to make a moderation team the highest authority in an organizational structure. I don't really agree with their demand to be the ultimate authority over everyone.

Violation or not, I wish they could have come to an agreement without throwing ambiguous accusations out into public as they quit. Between this and the "I refuse to let Amazon define Rust" post a few months ago we're getting a lot of drama with few, if any, details. There's a lot of "just trust me, but don't listen to what anyone else says about the situation" in this post.

Their closing statement asking everyone to not trust anything the core team says makes this feel particularly petty:

> We recommend that the broader Rust community and the future Mod Team exercise extreme skepticism of any statements by the Core Team (or members thereof) claiming to illuminate the situation.

I really hope that drama like this doesn't become one of the defining features of the Rust community.


I wish they were saying "trust me." What they're actually saying is, "I won't tell you anything, and don't trust anyone who does."

> IMO, it would be strange to make a moderation team the highest authority in an organizational structure. I don't really agree with their demand to be the ultimate authority over everyone.

I think it makes sense, scoped to their domain. Eg a security team can’t do their jobs effectively if they can’t apply their policies to the CO or if CO can arbitrarily undo it — security needs to have the last say on security policies, but that doesn’t put them on the top of the chain.

The same would be true with whoever does financial auditing and verifies everything is done to process & legally, as well as HR guarding against violations, and so on. The C*O must be held accountable as well, because their violations are also the most potentially damaging


Agree. What you want is a distribution of power like you got with modern, democratic state systems. As long as the moderation team is not an absolute power, I don't see an issue. If e.g. the COC is meant to be strictly applicable to everyone, then it needs to be enforceable for everyone.

Personally, I think absolute power hierarchies will sooner or later bring out the worst in people, attract bad personalities, no matter the appeal of a tale about leadership and ruthless decision making or whatever. Checks and balances will prevent things from starting to rot. A good foundation likely needs the expenses, work, "ineffectivity" of a thoughtful/elaborate distribution of power.


This kind of drama is already a defining feature of the Rust community. They can’t go 6 months without some kind of incident like this. It would be a positive if they could have a BDFL or corporate sponsorship to structure the community going forward because it doesn’t seem like the current community approach really works in practice. I realize that’s probably not possible at this point though.. unless maybe Microsoft steps in.

Disclosure: I am an outside observer, and I find Rust to be excessively syntax dense. Take my opinion with a grain of salt.


Having been a part of the community since a bit before 1.0, no this does not happen every 6 months.

I posted a link to Algolia’s full-text search index below.

> unless maybe Microsoft steps in.

I believe that would very quickly kill the community. Corporate MS cannot be patron here. You will never find me in a development community that puts compliance over people. I accept that in my job because it makes sense there and is necessary. But there are current sensibilities about conduct I do not share and I am not ready to keep up with the newest etiquette to be honest. I think moderators should go against obvious trolls and spammers, but aren't fit to mediate in conflicts.

HN has a strong moderation, but I think these are rules that the community accepts because everyone profits. It could just be a power grab by some mods that feel neglected, at least that is what they seem to display here.


I don't think the Rust community is particularly prone to public drama. What other events are you thinking of?

Recently? Linux, Amazon, “turbofish”.

Between Oct 2018 and Oct 2021...

https://hn.algolia.com/?dateEnd=1635638400&dateRange=custom&...


You searched "Rust" and "Drama", this is not exactly compelling.

First comment is referring to something that happened years ago.

Second comment isn't about Rust at all.

Third post is about Steve not liking something that came out of Amazon.

Reading on it appears to be more references to Actix, Amazon, totally unrelated/ irrelevant results, etc.


No kidding. It’s not a curated dataset, obviously. I looked through a few pages and filtered out the most recent few actual dramas:

1) Rust in the Linux kernel 2) Amazon MUST NOT define Rust 3) Turbofish issue

So, yeah, you have to do a bit more work to pull events from Algolia. It’s better than a feeling though and it’s real timestamped data. It’s not Google or Wikipedia though- the most relevant results aren’t just on page 1.


I don't think it's better than a feeling? Like, just a quick scan shows the same few things or totally unrelated content.

Honestly I don't think this proves anything, change "Rust" for "Python", "Java", "C++" or even "Javascript" and you will get a similar number of results with Python being actually higher than Rust.

I tried Java. Most of the hits are on sentences like "slowed down dramatically", "changed dramatically", and "latency shifts dramatically under load". There are also:

"So, upon hearing that the .net foundation is spending all of its time generating stacks of bureaucracy and causing internal drama"

"Oracle provides RHEL build and it's pretty good. No CentOS drama, it's free and just works."

"I'd be surprised if you found any dramas with the language."

There's no actual drama. Until page 4, when i find:

"Completely a drama"

In an article about Rust.


It’s not the number of search results, but the frequency of events. Admittedly, there isn’t anyone aggregating events and I only looked for the most recent 3 before stopping. I’m sure there’s some insider who’s better positioned to tell the history of the language and the community.

I dont remember any drama on Python, Java, C++ or JS on HN.

But I remember a lot of drama on Ruby and Rust.


> IMO, it would be strange to make a moderation team the highest authority in an organizational structure. I don't really agree with their demand to be the ultimate authority over everyone.

It is like HR staging a coup d'etat.


The same mod team member is strongly implying elsewhere that such a potential violation did occur:

>burntsushi ripgrep · rust 31 points 2 hours ago

>If we had an answer to your implied question it will necessarily reveal things (via obvious logical inferences) that we carefully avoided revealing in our statement.

https://old.reddit.com/r/rust/comments/qzme1z/moderation_tea...


On a side note, I absolutely love the Reddit Rust community. It's somehow devoid of all the anger, loaded harshness of pretty much any other subreddit or HN. So fucking respectful and friendly there. (At least, every time I visited.) I can only assume rustaceans are generally better people! Hanging out there is like a resort within the internet. Please, if you go there leave your edgy internet persona behind, but bring your bathing suit and a tasty cocktail, instead - enjoy life and programming.

FYI r/rust also has a mod team

I am sure they are doing a stellar job I am thankful for. However, you see very little [deleted] around, or many down-voted comments. I think it's really the community to praise, and their practiced tone and aspirations.

> they would have initiated a ban but they were not able to ban a core team member

If that was the case, the obvious response would be a formal statement of rebuke and censure wrt. the offending member's behavior, which would clarify that such things aren't welcome in the project. The fact that we aren't getting anything close to that extreme suggests that this is in fact a big fat nothingburger. (Unless you think that CoC violations are so widespread in the Rust Core Team that naming the specific people involved would have made no discernible difference, but so far we've seen nothing to indicate that.)


It might be that they cannot censure the offending member in any capacity, due to their core team member status. In that case, resignation is the only thing they have to effectively rebuke behavior.

As pointed out on r/rust, the approved Governance RFC states quite unambiguously that the Core Team is accountable to the community wrt. their behavior:

> Subteam, and especially core team members are also held to a high standard of behavior. Part of the reason to separate the moderation subteam is to ensure that CoC violations by Rust's leadership be addressed through the same independent body of moderators.

https://rust-lang.github.io/rfcs/1068-rust-governance.html


Public shaming by respected community members is probably somewhat effective. However, they chose not to do that here. Without knowing more, I have to trust their judgment. But I recognize that it’s unsatisfying.

This has a much worse effect though. Instead of damaging a single member they are now damaging the whole core team by leaving it unspecific, and they are damaging Rust as well.

I suspect that doing it this way puts pressure on the core team members who don't subscribe to the behaviors moderate the people on the core team who are problems. But one can never know.

Yes, that's how I read it too. At a guess, if the threat to resign didn't change anything the resignation also won't change anything and strongly suggesting the core team can not be trusted not to lie is a very harsh move that has the power to destabilize the whole Rust experiment. Massively dumb move this.

I think the only thing damaged is the concept to follow a COC to the letter. This was expected, people complained about it thoroughly and I think communities work better with a flexible approach as I don't think any personal conflicts have caused problems anywhere to a relevant degree. There are neither judges nor attorneys here.

It might be that the details would also damage the core team and The Rust community much worse with a flood of people leaving or people being targeted for harassment/abuse.

I'll give that the benefit of the doubt, but if that is the case then Rust is dead because if the core team can't be trusted to handle something like this then probably Rust as an experiment has failed, you won't get further corporates taking a gamble on Rust if this sort of cloud is hanging over the core team.

Well I think Amazon has a vested interest in the language at this point. Does the core team even matter that much now? If the core team falls apart could Amazon not simply pick up the reins? It doesn't seem to have hurt C# or Swift to be driven by a company.

There have been many points of friction in the history of C# and Swift caused by company-driven goals influencing the development of the language ecosystem in ways that some of their communities disagreed with. Leaving that aside, those languages were purpose-built by those companies for their use. Amazon didn’t create Rust, and it’s hard to imagine a hostile takeover would be received well.

Friction points are unavoidable. The point is they survived and have flourished under the direction of these companies who benefit from their continued existence.

I agree a hostile takeover would not be good for anyone but if the existing management structure turns out to be a roadblock maybe stewardship from a big tech company wouldn't be so bad.


Whether it’s better or worse is unknowable.

Yes, because if you accuse a group when you should be accusing an individual you are doing all of the people in the group a disservice. Then you should just say nothing. 'wie A zegt moet ook B zeggen'. If there are major upsides to this approach then I'm not aware of them, do tell.

TAN:

> 'wie A zegt moet ook B zeggen'.

Someone else mentioned "the Russian proverb, 'If you've said A, say B'"... In Swedish it's "Har man sagt A får man säga B". Seems rather international.


Is there any possibility they are under formal legal contract ie. NDA? Don't know how formal the Rust organization is setup/whether that would be a part in the process of joining the moderation team.

A moderation team under NDA might as well not exist. Moderators should always be free to speak their minds.

Is HR on the employees side? No. Same thing here, the moderation team didn't realize that their job was to protect the core team from the rest, holding the core team accountable wasn't a part of their job even if it was warranted.

An NDA for an open-source project? I sincerely hope no one tried that, but if they did, that's a radical idea and the effects must be studied (never let someone doing something weird go to waste, science can learn from it!)

I don't know what changes when formal structures like a foundation start getting involved.

I don't understand, why would you trust the judgement of volunteer moderators instead of core technical people?

Well obviously you wouldn't, on technical stuff, -- but that's not what this is about, now is it?

> I do think it's right for the mod team to not reveal the specifics in public; that would likely provoke targeted harassment and make the situation much worse

Instead, we have countless people bantering and taking "sides" about hypotheticals. In a world mostly devoid of secrets on the web, I think they could have, at the least, masked identities and summarized the issue.


It seems there is an internal communication channel for the Rust team? I thought that the moderation team would moderate discussions in open forums like mailing list or issue trackers, but in this case we don't know what happened behind closed doors.

Is there any good way to craft a message like this?

If they outlined specific issues then it would invariably devolve into armchair quarterbacking of those issues rather than the the underlying question of what kinds of checks-and-balances should exist for the Core Team -- gossip, accusations, and political discussions are a lot more fun than debating governance structures.

On the other hand, if no specific issues are raised then people are frustrated by having only a partial understanding. Because it's a lot simpler to evaluate an argument if you already know whose side you're on.


You're right, it's walking a tightrope. But they do put this at the end (on the Reddit post[0], not GitHub):

> we wish to ... focus on Constructive Criticism: how to improve the state of things, moving forward.

> There are many potential topics that are worth exploring: > What should the Rust Governance look like?

> How should the Rust Moderation Team be structured? What should be its responsibilities?

> How can we ensure accountability and integrity at the top? Who Watches The Watchers?

and I don't see how these can be meaningfully discussed by someone who doesn't know what went wrong. You can't diagnose and find a remedy for a problem that you can't even see. So while the sentiment "let's talk constructively" is fine, in public at least it seems like a non-starter.

Note that I'm not saying that this means they should publish a tell-all either -- but it needs to be recognized that, without that openness, the divide between insiders and outsiders remains. And the outsiders can't do anything constructive about these questions.

[0]:https://www.reddit.com/r/rust/comments/qzme1z/moderation_tea...


> and I don't see how these can be meaningfully discussed by someone who doesn't know what went wrong.

The "what went wrong" appears to be an organizational dispute, at least if we're to believe the statement.

Moderation team wanted authority over the core team. Core team disagreed. Moderation team resigned.

It's not clear that there was a violation, though their intentional vagueness does tend to push the reader to that assumption.


I hope it is as straightforward as that. But that's still not something that outsiders can see and help with.

I think the people who can fix this - the core team - know what is going on. The ball is in their court.

> You can't diagnose and find a remedy for a problem that you can't even see

The problem seems clear to me when I read the Github pull request, they can't enforce their moderation over the Core team. The remedy they suggest is for the community to decide how the moderation team should enforce moderation on the Core team (or if they should at all).

What would talking about the issue give more? It will just polarize people and push toward a specific solution for that specific issue, while the actual issue is over being able to moderate.


At a minimum, a public resignation has to say what it's in reaction to.

So no public resignations for people who are expected to not reveal details. So I guess "the entire moderation team has resigned and nobody says anything about it" is clearly the better the option?

There's nothing stopping you from doing it that way; it's just not very effective. A public resignation is usually designed to call attention to a problem, and trigger changes. If you don't say what the problems are with any specificity, it doesn't work as well.

> If they outlined specific issues...

I can't tell if a specific issue occurred, or if everyone is just assuming that there was an issue because the post is so vague.

They seem to make it clear that their primary complaint was about the organizational structure: They wanted to have authority over the core team, but they weren't given authority over the core team.


That just begs the question, authority to do what? If there are no specific incidents on which they disagree today, then is this just an attempt to position themselves better should any such incidents occur in the future? If there’s no problem today, why all the fireworks?

The other shoe is that if they let the core team be above the law, when an incident happens, there will be all sorts of accusations of impropriety.

> In this message, we have avoided airing specific grievances beyond unaccountability.

That makes it very clear that they had some specific grievances beyond unaccountability, otherwise it wouldn't sense to say they've avoided airing them.


> Is there any good way to craft a message like this?

"We are resigning and our reasons have been shared privately with X group. <eom>"

But since the goal of the whole exercise is to generate publicity and drama, the above was an unacceptable approach and the approach actually taken was highly effective.


I think that's an uncharitable interpretation. If your remit is to deal with issues like this, but you find the structure is broken enough that you can't do what you see as your job, what do you do?

Going public may be against the point of the group, but it might also be the only way seen to fix the problem and address the problems that prevent your group from doing its job.

So you're left with the unenviable option of explicitly doing what your team is not supposed to do in order to try to fix the team so it can function in the future. The responsible thing to do at that point would be to resign, so someone else can come in and gain the benefits you fought for, and your prior breaking of the rules does not taint the team.

I think that's the charitable view. I don't know if it's correct, but I do think it's worth considering.


They're committing to sharing these reasons with other Rust Team members, though. Just not the broader dev community.

Then don’t make a whole big public announcement about it. As someone from the outside this just reads like a post specifically to generate drama and attention but not giving details as to direct it at anyone in particular.

> Then don’t make a whole big public announcement about it.

I don't understand. How do you resign from a public project without resigning from that public project? If it is not about the resignation but about the message, do you think that a "we are resigning as a whole team that was made pbulic and we do not provide any public reason for that" would work any better?


They could have resigned without making a post about it. Is that a good idea? Maybe, it depends on the details we don't know.

And what, leave the Rust community not knowing that there's no CoC team because they've all resigned over something, but the community wasn't informed?

It's not like there's some membership card with paid dues. Their responsibility was to anyone that viewed themselves as part of the Rust community, and consumes anything to do with that community (whether or not they put anything into it).

Not informing all the people of that community because it appeases random public commenters would be a far worse failure of their duties than letting the general public gossip.


>leave the Rust community not knowing that there's no CoC team

They did have the option of finding replacements before leaving.


Employees have no duty to find replacements for their employer. There's especially no moral duty if your bosses are being jerks. I'd say that logic applies to this situation as well.

This isn't a post, it's a PR. If your names are listed in a public Git repository, then you need to have them removed if you resign. This means a PR and a review of that PR, which is exactly what happened here.

Alternative: They step down without an announcement, get replaced, somebody pieces it together and posts it on HN or reddit or something, and now you have all the same drama from announcing it publicly, plus all the added drama from the "secret step down".

Not sure that I'd call a PR a "whole big public announcement". Sure, it wound up here, but I don't think you can blame that on the mod team.

They also posted the resignation on the Rust subreddit: https://www.reddit.com/r/rust/comments/qzme1z/moderation_tea...

If matthieum hadn't done it, someone else would have (and has; some dupes have appeared and were subsequently removed).

There's a community of external contributors that deserve (or would appreciate) some notification about it though.

So set `X = "other Rust team members"`. Everything else in the comment was just for drama.

I don't think it was overly dramatic, but otherwise I agree with your point about pointing out another group with whom it has been shared, specifically a neutral party, if public muck-raking must be avoided at all costs. I made a similar point below: https://news.ycombinator.com/item?id=29308197

They should provide a timeline against which their actions will be explained.

A resignation is a public action, and as this team knows very well, such actions need to be held to account.


I have used Rust for years, but I never bothered with looking into the governance structure.

How are team members selected? Who has authority to kick someone off a team? How are team leads selected? Who can remove team leads?

Is it the core team? If so, who picks the core team?

I can't find anything online, except this very bare-bones WIP stub. [1]

This seems to be a glaring and surprising oversight.

Especially at this point, with Rust becoming more and more popular, the foundation in place for almost a year, and corporate interest flooding into the project, I would have expected proper procedures to already be in place for quite some time.

There certainly seem to be other cracks in the system. See for example "I refuse to let Amazon define Rust" by core team member Steve Klabnik, extensively discussed here on HN. [2]

[1] https://github.com/rust-lang/governance/blob/master/common/m...

[2] https://news.ycombinator.com/item?id=28513130


The core team is responsible for - Managing the overall direction of Rust, subteam leadership, and any cross-cutting issues

It doesn't sound like they directly work on the compiler?


Since Steve is on the core team, this certainly puts "I refuse to let Amazon define Rust" in a whole new light.

Maybe the problem wasn't Amazon, and HN shouldn't have jumped to conclusions so quickly...


kick off? Is this necessary for an open source non-profit project?

Of course it is. What if a contributor is harassing another team member? What if he/she is being openly racist/sexist/etc.?

I have yet to see significant sexism/racism in open source, but I have seen an insurmountable amount of drama, bad behavior, prosecution and prejudice from people proclaiming to fight against it.

The author of the message is BurntSushi. I have seen him communicate multiple times before and he seems to be a reasonable and intelligent person.

I cannot imagine that this action is frivolous.


I believe it. I don't think it is a significant problem in OSS that we suddenly need behavior rules but there can still be instances of something like that occurring. The most convincing action was to not release details in my opinion.

It's more about people vanishing or losing their marbles.

what IF a person in a responsibility position is openly accused of being XYZ-phobic by attention-seeking, emotionally unstable netizens?

Exactly. That's what a mod team should do: sort invalid accusations out from legitimate ones.

What if accusation is proven (and this person agrees with it) but said person does eir work really good. Should ey be forcefully removed from this position? What if there is no good replacement candidate at this time?

p.s. pronouns used are from https://www.orionsarm.com/eg-article/495360fba7a46 , I don't think singular they is correct thing.


Your PS seems conceited to me. Singular "they" is how the community of English-speakers handles this; it harks back to at least Shakespeare. It's miles more "correct" than any weird neologisms.

Obviously there is a story behind this ("the Core Team placing themselves unaccountable to anyone but themselves"), but it's not entirely evident from the PR itself what actions led down to this happening. I guess somewhere a Core Team member broke the Code of Conduct but the deed went unpunished? I was expecting some references or links to where this actually happened, but couldn't find anything. Anyone know what happened for this action to be taken by the moderation team?

Not part of the general Rust community, just an outsider, so maybe I'm missing something obvious.


Maybe is better that no single action is emphasized or a single person and focus on the actual problem, the fact that there might be a group that is above the laws/rules and possible solutions.

Edit: I think if some action will be made public then everyone will focus on debating why that action was correct/incorrect , then a lot of mostly politics dirt will be thrown around etc.


I'm generally in favor of enforcing high-level "behave professionally" norms in OSS communities. And not as a new phenomenon, either. I've been kick-banning disruptive people from IRC channels for several decades, I've run forums where I appointed mods, and I've always avoided participating in completely unmoderated communities beyond N=20 or so (not worth the headache).

But for some reason, the formalization of conduct enforcement stuff around OSS projects still feels weird, off-putting, and very "Corporate HR"-y to me. I still get a kinda awkward feeling every time I see a code of conduct in a freaking code repository as opposed to an MOTD or mailing list welcome email or the like. The contents is normally reasonable and if it were in one of those other formats it'd feel normal, but checked into a code repo just feels wildly out of place and needlessly in-your-face?

Maybe I'm just getting old.


With most OSS projects nowadays I don't think you have to use a mailing list or anything that would have an MOTD in order to contribute. Contributions nowadays are often done entirely through the repository, so it makes sense to put in them the things that people contemplating contribution should be cognizant of.

Repositories for most projects are more project repositories than mere code repositories.


> Repositories for most projects are more project repositories than mere code repositories.

Indeed, but for some reason it still feels odd. I've acknowledged I'm getting old, right? ;-)

Also, there is some rational justification to my feeling. It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contributions. But if they made a technically meritorious merge request via SCM the contribution would still get due consideration. Even assholes can be good programmers, after all. That always felt healthy & mature to me. Finding a way to protect the masses from assholes without exiling the asshole always felt like a sign of good community stewardship. It's something I strived to do in communities I moderated.

So, what? I guess this: Bundling the CoC into the repo violates this expectation. Just because someone couldn't get along doesn't mean we kick them out of the hobby. I think that's why it makes me uncomfortable.

In a hobby org, you don't let the known jerk on the board. You definitely don't let him man the booth at community outreach events! However, you also don't usually kick him out of the core activity. In a non-OSS hobby context, I've had folks steal things but still allowed them to stay in the community while taking away unsupervised physical access to common property. Measured tolerance and forgiveness are both important virtues, and sticking around in a community after public humiliation shows a commendable level of commitment to the hobby/community. The social bonding that happens via the process of apology and forgiveness often does far more good for the community than the harm of the infraction.

But, also, I've always considered OSS a hobby scene rather than a business model or resume booster. I guess if an OSS project is just a way for companies to commodify complements and for contributors to get jobs, then treating it like a Fortune 500 all-hands makes sense. But I'm not interested in those types of communities; I have hobbies, and programming can be a hobby for me, but I charge a lot for my labor and would never, ever work in a corporate environment for free.

I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are.

Again, getting old I guess.


> Indeed, but for some reason it still feels odd.

I think putting the CoC into the repo is mainly to clarify that it applies to discussions on the issue tracker. If GitHub didn't also do issue tracking and other things where actual discussions occur, there would probably be fewer CoCs in repos.

> Measured tolerance and forgiveness are both important virtues

There are a small number of extremely toxic people in positions of power who will abuse "forgiveness" in order to deliberately commit an unending series of abuses on a string of people. People kept "forgiving" Harvey Weinstein for decades. The line between tolerance and enabling can get hard to distinguish, especially when someone has enough power to control the narrative.

So a community must be aware that its tolerance mechanisms can themselves be maliciously abused. But the alternative—intolerance and being unwilling to forgive—ends up harming the larger number of people who are fallible, do hurtful things, but can be remediated. It gives less room for people to be human.

Finding the balance between these opposing forces is hard. A maximally efficient and happy community is one of complete trust between all participants. But that is also the definition of a maximally vulnerable and exploitable one.

> But, also, I've always considered OSS a hobby scene rather than a business model or resume booster.

That line got really blurry when open source ate the world and many large tech companies now work heavily with open source. You have many employees (like myself) who work on open source projects full time at work. And you have others who work on open source because it helps them find employment at companies that use that code.


This is a super mature, nuanced post so thanks for that.

> It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contributions. But if they made a technically meritorious merge request via SCM the contribution would still get due consideration. Even assholes can be good programmers, after all. That always felt healthy & mature to me. Finding a way to protect the masses from assholes without exiling the asshole always felt like a sign of good community stewardship. It's something I strived to do in communities I moderated.

To some extent I think this is because GitHub doesn't offer the same tools that running your own mailing list would. A mailing list can do what you said, /dev/null ML contributions while still letting patches through. That's not something you can do easily in GitHub.

> I guess if an OSS project is just a way for companies to commodify complements and for contributors to get jobs, then treating it like a Fortune 500 all-hands makes sense.

Rust has a pretty friendly community (from what I've encountered at least), but a lot of its core stakeholders do have a lot of corporate obligations, and many of them Rust related. It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job.

> I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are.

Github is part of it, but in general I think a lot of today's OSS projects don't have a strict separation of "community" and "code" in the way that projects in the past used to. Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation, and that older tools like mailing lists are cumbersome enough to maintain that newer developers don't actually explore using them very often.


> [Moderation is] not something you can do easily in GitHub

That seems like a pretty significant design flaw :(

> Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation [between "community" and "code"]

Indeed, this makes perfect sense.

> It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job.

Yup, totally fair and makes sense.


I'm 30 and that paragraph about OSS vs F500 resonates with me. I don't know how far it goes towards explaining all of my own tastes in OSS community, but the corporate sterility is definitely showing up to different levels in various places. It's the kind of thing I find offputting in and of itself, without even knowing what it's being used to enforce.

The assumption here is that any violation of the Code of Conduct would result in the offender being instantly kicked out, right?

But there are other ways to deal with actions that go against a code of conduct, to de-escalate situations and encourage rehabilitation within the project - just like what a healthy project would do without an explicit code of conduct.

Because let's be honest - those hobby groups you're talking about almost certainly did have a code of conduct, but it was probably implicit and uncodified.


The vast majority of open source projects do not create their own open source license- most of them choose from a relatively small selection of widely used licenses (GPL, BSD, MIT, Apache, etc.).

Why then do so many project choose to roll their own CoC? I'd expect that there would also be a relatively small handful of widely used CoCs to choose from, and a project could pick based on their projects' needs.


I'd wager this is because there is one outright leader in the field (the Contributor Covenant) who's author has at times been a controversial figure in her views on enforcement and scope of codes of conduct, which can lead to people being apprehensive of just adopting the popular example.

You can see similar with licenses. Stallman was initially controversial for his views on software licensing, and so in the early days there was a proliferation of licenses like the eclipse public license, mozilla public license, microsoft public license, CCDL, etc.


I'm on a tiny project without a CoC because I don't know how to enforce it if we had one. Enforce means it needs to apply to me, and also whoever enforces it needs to be active to watch for issues. I wish KDE/Gnome/other big project would just do a CoC as a service for tiny projects. For the most part the CoC should be standard, and a few experts to enforce it would be better than random enforcement. (note I have no idea if the above is possible)

I don't think it makes sense to have a CoC beyond "Don't be a jerk" until you have multiple teams and more complex governance structures.

> For the most part the CoC should be standard, and a few experts to enforce it would be better than random enforcement.

I've heard that large-scale enforcement of CoC is super easy and that all the big social media companies have it figured out ;-)


I don't think you can really have good moderation of a stable group without the moderators being members of the group themselves -- and known and trusted/viewed positively by a majority. Otherwise they'll just be perceived as jerk outsiders who swoop in to make more trouble than they solve. And they will face constant pushback and non-compliance.

>But for some reason, the formalization of conduct enforcement stuff around OSS projects still feels weird, off-putting, and very "Corporate HR"-y to me.

But if a community already approved such rules is it OK that those would not apply equally for all? Before joining a new community I always check and see if there is a lot of toxicity or just low effort contributions and I am avoiding those, it would suck to join a community because they promise moderation and later you see that the rules don't apply equally.


Maybe it will help to explicate what rubs me the wrong way about "corporate HR".

The facade of process masking Machiavellian reality is what rubs me the wrong way.

I'm always astounded by folks who don't understand that companies are feudal kingdoms and that all the stuff about processes and protecting people who are innocent/do the right thing is just hot air. And I've never been on the wrong side of HR, so this isn't a personal issue per se. But when I mentor new grads, I do make sure to find some time to explain how companies really work and stress that "getting along" with people is the most important skill.

I've always felt like the world would be a better place -- and workplaces would function better -- if Corporate HR was just honest: "this company is someone else's property, you have no rights to that property, we do what we want, so play nice and don't piss off the wrong folks unless you're ok leaving."

Most OSS projects aren't so dissimilar. I don't know about Rust, and suspect "Core" might have a different meaning here. But in most projects the core (aka primary) developers effectively own the project. Rules to the contrary are at best aspirational and at worst lies. If you disagree with the primary developers, it's much better the just fork the project than to imagine that there's some fair and rational process by which you will be able to plead your case and over-ride their edicts. Again, this isn't a value judgement. It's just a description of how reality works.


I have a nagging feeling the rules are different in fields like sales, trading, sports, or others where performance is more precisely quantified.

The reality, somewhat sad in my view, is that in most places, software shops, architecture firms, academia, pretty much anywhere where individual measurement isn't possible and most work is done in teams, most performance reviews are a thin veneer over a high school popularity contest. You get ahead by being liked, something that's at best loosely correlated to how much work you get done, or at what quality.

Of note, the best manager I worked for (in software) ran a great team by making work about the work, not being liked, or delivering great powerpoints, or other secondary things.


> sales

Most types of sales labor is a complete commodity. For every one high-powered b2b software sales person there are hundreds of folks selling commodity laptops to rural schools, pushing trim upgrades in car dealerships, cold-calling convenience store owners, etc. The high school politics in those sorts of sales shops are next-level.

> trading

Trading desks are often whole orgs, often with diffuse and difficult to measure contributions. Not so dissimilar from software shops, really. In fact, often literally are software shops!

> sports

I don't have first-hand experience with anything other than climbing and skiing, where "hussle" and getting along with everyone from sponsors to gym/resort owners to random community members is way more important than raw talent. At the end of the day you're basically an influencer. Instead of HR imposing rules to help with reputation management work, you're doing the HR reputation management job yourself.


> "this company is someone else's property, you have no rights to that property, we do what we want, so play nice and don't piss off the wrong folks unless you're ok leaving."

> so play nice and don't piss off the wrong folks

"Play nice", "don't piss off" and "the wrong folks" are open to interpretation. I think having these at least somewhat codified is very helpful. Cultures differ a lot, and what may be considered "a useful, clear, concise and honest code review" in one is "blatant non-constructive shitstorm from an arrogant a-hole" in another.

However, such codification probably requires specific examples rather than "please be respectful to all people regardless of X, Y, Z" or "don't piss off people". For example, I really like how Recurse Center's "Social Rules" are described: https://web.archive.org/web/20211117232710/https://www.recur...

> Most of our social rules really boil down to "don't be a jerk" or "don't be annoying." Of course, almost nobody sets out to be a jerk or annoying, so telling people not to be jerks isn't a very productive strategy. That's why our social rules are designed to curtail specific behavior we've found to be destructive to a supportive, productive, and fun learning environment.


> "Play nice", "don't piss off" and "the wrong folks" are open to interpretation.

Yup. It's sometimes hard to figure out how power flows and the social preferences of the people who modulate those flows. Getting along in large orgs is a skill that requires both experience and intentional work.

The problem is that people rarely run into trouble due to abrasiveness among peers, so examples like the Recurse center can be helpful but are woefully incomplete as a guide to corporate politics.

Getting along while being ambitious is anything but easy. There are no rules.

At the end of the day, "social skills" and "social intelligence" are just that -- forms of skill and intelligence. "Getting Along" is always a learned behavior, albiet does come more naturally to some than others, and is far easier said than done.

These skills are often learned pretty early on in life. It's one of the reasons I encourage folks who are considering home-schooling to at least send their kids to one year of high school.


The problem is that people want the facade. I generally expect managers to present themselves as first among equals, even though I understand in extremis that's not true, and I wouldn't work in an organization where they do a bad job at pretending. It's my understanding that my mindset is pretty common, although I have to admit that I'm not sure because this isn't the kind of thing I'm comfortable polling my coworkers about.

My post is about HR processes, not management relationships. And what I said about the ultimate authority was about ownership, not management.

Managers are also just laborers. As laborers, they also need to know that "getting along with people" is most important.

> I generally expect managers to present themselves as first among equals, even though I understand in extremis that's not true, and I wouldn't work in an organization where they do a bad job at pretending.

If you're a senior engineer making anything less than 500k or so, your first-line and even second-line managers do have a complicated power relationship with you.

I.e., another way of saying what you said here is that your labor is in high enough demand that your mangers have to treat you with a certain amount of respect in day-to-day interactions.

A manager who doesn't show enough politeness/deference will have high turn-over, and in most situations that spells problems. Again, because they aren't capital owners. They are laborers.

Like I said, "getting along with people" is probably the most important skill. Finding yourself in an HR process means you failed at "getting along with people". The rest is noise. Don't rely on HR. Get along with people.


This 100 times this. It's especially weird since the whole idea of open source was that you can just fork a project if you don't like it.

HR rules don't typically apply to executives even when it's stated that they apply to executives.

What's "a community" here?

If this "moderation team" felt that there is no option but to quit, that means that they were rejected by the community, complete with the "CoC" they tried to enforce.

Seems like everything is fine to me.


For me seems they were rejected by the core team, no idea who elected the moderators and who elected the core team , I do not know if Rust is a democracy and works like Debian or is different, I will try to inform myself though.

Large OSS projects are largely staffed by corporate contributors - the culture shift in the organisations paying the contributors is reflected in the projects and the communities surrounding them.

How exactly are the groups of people working on various parts of the official ecosystem supposed to coordinate their efforts? The only alternative I've seen is a benevolent dictator, which seems significantly worse for a number of reasons.

Edit: it looks like you've removed the part about Teams/Committees.


As a matter of fact no, benevolent dictator is not significantly worse. In fact historical evidence when it comes to OSS projects points to the benevolent dictator model being the most effective. It may not satisfy social justice activists pretending to be competent programmers demanding a seat at a table that they never earned, but most successful projects are not ruled by committee until they reach a significant level of maturation, and it’s arguable their development slows down quite a bit at that point.

> benevolent dictator is not significantly worse

I think your normative justification for project dictatorship misses the more important point: there's probably a dictatorship either way.

In these cases, the main advantage of the overt dictatorship model over the layer of indirection dictatorship model is that you at least know who's really in charge.

In some odd sense, the mod team that just resigned is in agreement: their resignation lays vare exactly who's in charge.


The benevolent dictator might have too much sway in some project, although in most cases it literary is his project. Problem with enforcing compliance of behavior is that this becomes the raison d'être. This will always fail in any configuration at some point. We are talking about people and if their rulings don't find acceptance, they will interpret it as a personal attack. I am not above that, you are not above that and nobody really is. I have no info about this case, but it fits the profile.

I only take active part in smaller OSS projects and corporate rules in general do suck the fun out of it. Maybe Rust is beyond that, but I would vastly prefer the eccentric dictator to corporate HR, because the latter is nothing else. The dictator or developer has other ambitions aside from behavior enforcement, so it is easier to cooperate.

And if you do not like the dictator, you might be able to fork the project and make it conform to your personal views to the same (overbearing) degree. Win-win.


Far too many promising open source projects have disappeared because the benevolent dictator lost interest and disappeared without leaving an empowered community. Far too many promising open source projects withered and died because the not-actually-benevolent dictator turned off every would-be contributor.

In the scope of things, these are much more common that the few examples of projects that succeeded in spite of low bus factor and toxicity.


The code doesn't cease to exist. If one person is doing all the heavy lifting and decides to stop, it isn't their fault for not creating a social hierarchy.

yea, sorry, I tend to over-use the "edit" button and treat "submit" as "save draft".

> How exactly are the groups of people working on various parts of the official ecosystem supposed to coordinate their efforts? The only alternative I've seen is a benevolent dictator, which seems significantly worse for a number of reasons.

Yeah, I guess I'm just getting old. The idea of an open source project with enough people to form an entire committee of moderators also feels weird, but is apparently fairly normal these days.


It's our industry that's getting old. You used to be able to start a big project like a compiler or a browser and have some hope of producing a functional result "organically" (for lack of a better word). But we've reached the point where we're no longer just scrabbling together hovels with scrap wood, we're trying to build the Pyramids or the Hoover Dam now. A few anonymous internet denizens are not going to be able to accomplish that.

Sure. And I dislike corporate BS but happily work in corporations as long as I can mostly get away with nothing but the most surface-level acknowledgment that the shit does indeed smell like roses. (And like 90+% of what HR enforces is mostly good anyways; pretending it's not a facade is often a small price to pay for the level of nonsense I'm shielded from)

Again, I'm not even necessarily saying things should be different or proposing a better alternative. Just expressing a feeling.

If could change one thing in the corporate world, it wouldn't be to change how corporations work. Simply disabusing people of fantasies about how corporations work would be far better than any incremental improvement.

I guess I feel the same way about OSS codes of conduct. They're facade. To the extent that they're enforced, it's because the wizard behind the CoC curtain allows this to the case.

Should anything be changed? IDK, but everyone understanding this would probably be preferable to any incremental change to project governance. If that makes sense.


Late to the party, but I strongly agree with your comments in this thread, based on similar experience in a corporate environment.

The weird paradox in this governance model is why we see so much fluff around the actual autocracy that - at the end of the day - is what matters. Why pay for HR, townhall events etc, etc, if in the end it doesn't matter?

I think the obvious reason is - ironically - making accountability optional, through selective enforcement. If you have an arbitrary and emotionally based strict set of rules, you can freely accuse practically anyone for breaking it, since the owners have last say anyway. As such, you can say "sorry, we had to let Tim go, because he violated policy" - and abracadabra, nobody is personally accountable. It's the woke equivalent of a firing squad.

In fact, if a process is not universal, but selective, it is just a power tool. And what's more attractive than a power tool? Simply throw process on people you dislike, and let the people you like through.

That's not to say there's some calculated malicious intent behind this. There are tons of people who genuinely think these systems are good and serve them, or people less privileged than them.


> focus on the actual problem, the fact that there might be a group that is above the laws/rules and possible solutions

I just find it hard to understand on how you are suppose to see if the group is above the rules or how you can find any possible solutions, when what is supposed to have exemplified the problem is kept in the dark.


The people who own the project, own the project.

The people who own your employer, own your employer.

Does that sometimes suck? Sure. Is it often unjust? Absolutely. Do you sometimes need to switch jobs or fork a project? Yup (see: mod team resigning).

But don't ever get confused and think that an HR process can save you from the whims of your master, and don't ever believe a "rule" that says the owner of something is constrained. Unless there's a higher power that can enforce that rule (e.g., a government or a market). And even then, the rule isn't doing any of the lifting.


> I just find it hard to understand on how you are suppose to see if the group is above the rules or how you can find any possible solutions

Perhaps you aren't?

This is still an internal Rust team issue; it's not a problem for us, a bunch of randos on the Internet, to solve. Our job is just to gawp from a distance, maybe gossip on Hacker News a bit.


It doesn't look like an internal Rust issue when the moderation team disappears while saying "If the Core Team says anything about us/the situation, be careful about trusting it without verifying first" in a very public venue.

If they really wanted to keep it internal, it would require even less effort to just remove themselves from the moderation list with a "We resign" message without further detail.


They didn't send you a personal e-mail. They made a PR changing their team status to "alumni" and included the requisite justification in the PR message.

That doesn't mean it does not affect anyone outside leadership. It's government, they make decisions that affect participants. There's no such thing as a completely 'inside baseball' issue in government, unless you aren't a citizen. If you don't use Rust at all, you are free to feel like you do not need to think about solutions.

I would argue that it's governance, not government.

It was a metaphor, for the citizen analogy. There is ultimately very little difference in terms of the shape of these problems.

True. But what differences there are, are critical.

They also formally published this on Reddit.

They are saying that if those people keep it up, they can't have a Mod Team. It is an expression of an incompatibility between expansive power residing in the Core Team and the existence of a Mod Team. You don't really need a specific situation to see how that could obviously happen (classic power struggle), or to believe it has recently happened. Story as old as time.

At its height, this resignation constitutes (a) a plea for people in power to exercise it better, and (b) for those people to voluntarily become more accountable for some pattern of behaviour. (A) might be effective, if only because Rust governance so far prides itself on all the things that come with having a Mod Team. Not having one is embarrassing.

But point (b), which is indeed the focus of the resignation message, is plain magical thinking to my eye. Accountability I understand it is the acceptance of responsibility, by someone, for some thing. Someone else fundamentally needs to know what that something is for that to happen. It cannot happen if the thing is kept completely under wraps, but it can be approximated with limited but trustworthy disclosure, and this is the basis for the levels upon levels of that in e.g. national security regulation. That is a very difficult problem in its specifics, but the theory is simple: inform someone trustworthy and neutral, and then tell everyone else that you informed them.

What this message lacks is any indication of which people do know what the specific acts by Core Team members were and who did them, and what position those people are in to verify if anything is done about it. If you are unwilling to muck-rake in public, you need to give everyone else a proxy by which to gauge your generic claims. In normal governments this takes many many forms, including ministers, Inspectors-General, privileged parliamentary committees, etc. But you do not need a formal role, you simply have to nominate someone outside your group and your opposition (ie appears neutral on the face of it) that is aware of the facts. Without that, everybody who sees this will have to gauge your claims on the extremely minimal information provided plus your own reputation, but with no credible claim to neutrality on the issue. Even one such person would be better than all of the co-signatures on that letter combined.


> What this message lacks is any indication of which people do know what the specific acts by Core Team members were and who did them, and what position those people are in to verify if anything is done about it.

The answer(s) to that is (are) probably: The whole Core Team knows, and since they apparently aren't accountable to the Mod Team, the only entity that can do anything about it is the Core Team as a whole. So the ball is in the Core Team's court.


A group being "above the rules" is, I think, a statement about what the rules are and how they are enforced. It doesn't really hinge on whether any members of that group have, up to this point, violated the rules.

Probably by the rules, say if the existing rules have exceptions for the core team so making this core team above the existing laws.

Without knowing exactly what went wrong it won't be possible for the community to know if their changes have gone far enough (or too far) to address the actual problem.

This stinks. I wonder if the moderators are concerned they'll be found culpable as well, if the problem is revealed.


Being a moderator is a thankless job, and when you don't have any power to do that job, it also becomes soul-sucking.

I don't think the moderators are concerned about culpability. I think they're concerned that what appears to be an internal debate is going to get dragged out for months on end, in public, with all context loss, and with even less ability on their part to do anything useful or constructive.

If I were in their position, I would very likely do the same thing and try to learn some lessons and move on with my life.


They explicitly say they are not saying:

> In this message, we have avoided airing specific grievances beyond unaccountability. We've chosen to maintain discretion and confidentiality. We recommend that the broader Rust community and the future Mod Team exercise extreme skepticism of any statements by the Core Team (or members thereof) claiming to illuminate the situation.

With the earlier bit about the Core Team not having to adhere to the Code of Conduct, it could mean something awful has happened and a Rust Core Member is above justice or pressuring the mod team’s investigation?


Which is a pity. I always saw the Rust organization as one that acted in public and with transparency, I guess that's why I expected something more clear instead of a resignation of a full team without any further clarification about why.

But, of course up to them what they feel comfortable sharing with the public, if it's something that has to stay private I guess that's the way it will be.


There are always types of events that are not suitable for public discourse (pretty much any form of harassment or abuse, where victims are still subject to pressure or were yet unable to process what happened falls into this category). I have no insight into what happened but it's not hard for me to imagine what could prompt moderation team to resign w/o disclosing specific instances.

Right. It may also be possible that there is some hope of this action restoring normality. i.e. as a result of this protest, the Core Team become more accountable. At that point, I assume the specific incident(s) may be dealt with according to the Code of Conduct, which may or may not involve transparency. Either way, it could be premature and possibly prejudicial to air those now.

I just hope it's not about either something silly (like tabs vs spaces) or something important but unrelated (like BLM).

Honestly speaking, the fact that they are not giving any details makes me think that it’s either something minor (but sides were taken) or it’s something political and divisive.

One would assume that the Mod team would be the first to air something egregious. The fact that they aren’t tells me they don’t like the optics of the issue and they’d rather stay silent.


> The Rust Moderation Team (Andre, Andrew and Matthieu)

Is the Rust mod team really just 3 people?

I'm really surprised to see this coming from Rust. I've viewed Rust's governance as one of the best amongst open source projects. Coincidentally we have very recently put together a mod team in Nim[1] that is significantly larger than just 3, it would be really great to hear more details so we can learn from this.

1 - https://forum.nim-lang.org/t/8629


It was 4 people until very recently. But it was only 4 for a long time. It's inaugural size (of which I was a part) was bigger than that. People leave over time and it's hard to get new members.

We acknowledged this in our statement. We suggested that the future mod team do a better job recruiting new members than we did.


I very much dislike COCs and overbearing moderation teams in open source communities. Good on you that you didn't publicize anything, that is probably the hardest for you than for anyone else.

The Rust leadership doesn't make a good impression to be honest. I like the language itself but it isn't really an open source community I would want to engage in aside from the technical aspects (my involvement is limited in any communities because I mostly write commercial software, just dabble here and there, although I am clearly dependent on open source and try to point that out to those less positively inclined to the concept).

What really interests me is why you believe such COCs are necessary. Do you believe they improve open source communities? It is a necessary evil if a certain popularity is reached? Is formalization an attempt at transparency? As I said I dislike COCs, but the Rust one has less than 300 words. Does this reach any target audiences? Is "professionalism" worth striving for?

In my capacity as a developer I have professional exchange in a corporate setting. Sure that every corporation has their own behavior rules, but there is never a formal framework for such engagements that mostly involves people from different companies. Perhaps people behave better because otherwise their job is on the line, but why does it work here? And I believe for many working in such a setting a more "direct" method of mutual engagement seems kind of refreshing. Would be sad if open source tried to mimic the corporate work. There is no greener grass here.


My views on Codes of Conduct are pretty nuanced, and frankly, I learned a long time ago that the Internet cannot handle nuance. I was and still am an enthusiastic supporter of Rust's CoC, but you'll also notice that none of my personal projects have a CoC in them. So from that alone, you might at least surmise that I don't necessarily think CoCs are a universally good idea (or more precisely, "worth it") in literally every situation. Equivalently, I think they are a good idea in some situations. But I'm not going to say much more than that.

> I very much dislike COCs and overbearing moderation teams in open source communities.

Same. And I have avoided some such communities in the past.

But, I am not necessarily against overbearing moderation. For example, r/askhistorians is one of my favorite subreddits, and I would attribute that state to their intense moderation.


Thanks for your answer. The Rust COC is certainly short and concise, which I prefer if we really need them at all that is. There certainly are also situations where moderation can keep things on topic. When I say moderation I mostly mean tone policing or sanctioning certain views, not the removal of spam or memes that dillute a topic, although the latter at some point comes down to opinion too.

I had this 2 star repos for a niche problem with perhaps 2-3 visitors per month and someone quite aggressively suggested that I should put one up. At the same time more an more projects put one up and I wondered where this push in OSS came from.

Suddenly projects needed committees to enforce some form of weird compliance. I just think it didn't improve conduct in any community that I saw. Not that you have to look very far to find eccentric personalities but I never thought that to be a problem, on the contrary.


I just went to askhistorians and the front page has no un-deleted answers as far as I can tell. So, utterly dead community that only had a limited time in the spotlight, supported by unsustainable heroic effort of unpaid volunteers.

I don't know what you're talking about. There's one right here[1]. I've been reading that subreddit almost daily for years. I still do. It's not even remotely dead.

[1] - https://old.reddit.com/r/AskHistorians/comments/r0en25/what_...


A code of conduct is there so that everyone knows what the rules are, and can refer to them when moderating (including self-moderating) interactions within the community. I'd consider it a big upgrade over when I was in charge of moderating an online community, and formal COCs weren't a common thing yet. The rules, such as they were, were largely informal and unwritten. In consequence, that mod team was very much a star chamber. It wasn't great. Sunlight is the best disinfectant.

Inter-corporate communication is not a good analogy here, because inter-corporate communication can't generally be modeled as a set of individuals freely associating with each other. Their status as representatives of their employers significantly changes the landscape. Companies are generally careful not to install people with less-than-stellar communication skills at their interfaces with other companies in the first place. I suppose the maxim to trot out here is, "An ounce of prevention is worth a pound of cure."


Thanks for your contribution burntsushi. I'm sorry it has come to this.

Thanking the political commissars?

I’m glad to see them resign, and I hope open source can ultimately route around the unearned power grab that the “CoC” movement represents.


I actually disagree with 2 parts of your premise

1. I don't think we're actually talking about that much power, in most instances the issues amount to "not behaving professionally in an environment that wants to have a professional character"

2. What would it need to be for you to consider what power it gives as "earned"? I'm surprised since it seems that power being explicitly delegated by the project should be enough by any measure.


Specifically, how do you feel someone like burntsushi represented an unearned power grab? Go on, I'm listening.

Actually this time it's the opposite. The moderators' refusal to elaborate unfortunately lends itself to your position and it was my knee-jerk reaction too until I found out the conjunctured details.

They do suggest that the next mod team spend more time recruiting...

Curious, why did a project of programming language hire a multi-person moderation team in the first place? That's the OSS version of HR? Or is it equivalent to a team of diversity and inclusion?

> hire

Not hired, but voluntary.

> moderation team in the first place

Because a community of any larger size needs moderation (small communities tend to self moderate, larger communities without any form of moderation are at serve risk of becoming toxic and/or unwelcoming places).

> OSS version of HR

Oversimplified it's a Team which steps in when the Code of Conduct is (potentially) violated to moderate (i.e. resolve) the situation with the goal of keeping the community open, friendly and well coming.


> it's a Team which steps in when the Code of Conduct is (potentially) violated to moderate (i.e. resolve) the situation with the goal of keeping the community open, friendly and well coming

And how would you describe HR?


Department responsible for managing employees?

The difference is the moderation Team does only moderation.

But HR does all kinds of things, which often (but not always) includes moderation.


People have made fun of Linux having Linus as the dictator on top, but it seems like that model might be the best for long term project success...

Right, and Ruby has had Matz, Python had Guido and to a certain degree PHP had Rasmus. As soon as you have more than one captain in the ship, politics and drama seems unavoidable.

Agreed, a single point of authority is useful.

Although in this scenario, isn't code of conduct something much more "local" that the ringleader doesn't really need to step in every time to enforce?

CoC is just something I expect everybody to enforce when needed. Having a dedicated team to do that seems odd to me. I guess you still need someone to issue bans and to wield the ban hammer, but it _should_ happen infrequently that simply informing the violator of their violation should be enough (unless they're a troll and will continue violating, in which case they can be kicked).


Didn't Guido resign due to politics[0]? I think politics is an issue of organization size more so than structure.

[0] https://mail.python.org/pipermail/python-committers/2018-Jul...


Linus was also nearly driven out by "activists". Best I can tell he never actually said or did anything egregious - his European directness and sense of humor just upset some particularly fragile folks on the mailing list, and so did his refusal to grovel before them.

That said burntsushi at least doesn't seem like an activist to me, so the grievances are probably legitimate. Coming from someone less prominent they'd not have anywhere near the same weight in my eyes. We just don't know what they are.


I remember a person from current Rust's core team cheering when that person thought Linus is getting ousted from the project.

I take Linux organizational model over Rust's every day. A group of super competent people with no bullshit policy. It is proven. The problem is how to form the successor to the dictator.


I think the case of Rust is a bit unique with heavy interest in the future of the language from powerful companies [0].

[0] https://news.ycombinator.com/item?id=28513130


Not sure that's unique; Linux surely also has powerful companies interested in influencing its future.

Survival bias. The benevolent dictator role works if you get the right one.

Postgres has a core team, FreeBSD has one, C++ has a steering committee. You can find examples for whatever variant of governance you want. The "one person calls all the shots" model certainly can work. It can also fail and it often has (usually when said person has no interest anymore, but no successor is available or has the clout needed to succeed them).

Same with company CEO's as well

More likely the latter. HR usually has a mission to protect the company (project in this case). CoC and its moderation usually just serve the purpose of virtue signaling or maybe even carrying out a digital version of a struggle session, so D&I seems like a good analog.

Programming Language authors love to formalize everything, but did Rust really need all of these rules and moderators to begin with?

Absolutely, yes. A growing community needs healthy management in order to avoid reputational damage to the core language. There's no shortage of guidance to "stay away from X tech because the community is toxic and non-serious"

In my experience the people who, when asked about the technical merits of X, immediately dive into value judgements of a “community” around it are best ignored.

If these types of people are in leadership positions, it’s too late and you need to move. If they’re below you, then you need to limit their reach and upward mobility.

Usually fair application of performance standards will flush them out anyways. Often people like that in your organization are shielded by a manager that’s protecting them.


Woah, mate. I think that way of thinking might be more-than-slightly career limiting.

The community does play a role in the ecosystem you’re buying into. You will most likely need to send PR’s / bug reports in at some point. If the core team tends to ignore bugs/external contributions, it is a point to consider.

Furthermore, if your first knee-jerk reaction to the behaviour you think undesirable in reports is to “limit their reach and upward mobility” I think you need to think seriously about what mentorship means.


in my short experience in software (7 years), it almost feels like there is more drama when a CoC mod team is involved.

without a mod team, you will still boot trolls or resolve a dispute. I think it's better to have a judge who can step in and resolve a situation than proactive police when it comes to OSS moderation.


Depends on your POV

My POV is one of privilege (I hate that word and concept, but it fits here). Being part of the majority most of the ways you can slice IT - except I am older but that one was a change!

In other fields I was made aware of what it is like to be part of other groups, and it can suck. I got married. My spouse took me on a tour playing "spot the detective". They got followed around shops in a way that never happens to me. When we stood together at a bar, they were served after me, every time.

A lot of people here know this from personal experience, a lot of people here it is academic reality, a lot of people here simply do not understand. OK. Believe me, it is real

I have been involved in groups that make efforts to embrace people from outside the main dominant (majority) slices (how ever you choose to slice it) and groups that do not. The former is much better.

Rust has truly benefited from it. Those in the comfy majority, it turns out, benefit too. I do.

Compare Rust and Swift (I use Swift professionally, Rust for fun) There is no comparison. Swift has so many corners that have not been rounded off. The ergonomics is mostly much worse (unwrap V ! is an exception). Memory management in Swift is almost non-existent, the threading model is appallingly bad. I could go on, but on one side is a vibrant community, on the other is a bunch of alphas, astroturf, and the weeds rolling through almost empty Apple forums.

The mod teams are a very important part of making the community a good place, making the community a good place is crucial for making the technology good.


> mod teams are a very important part of making the community a good place, making the community a good place is crucial for making the technology good.

Moderation teams are the cultural equivalent of a code smell.

The role of moderation is strictly to remove spam and move off-topic chit chat to the off topic bin. The expanded post-modern role of “moderation” is inherently toxic and degrading.


I would think more likely all the drama and more is still there without a CoC or a team to enforce it, it’s just hush-hushed and allowed to fester. The world is chock full of examples of communities quietly condoning horribly toxic and outright criminal deeds and abuses, often toward less privileged people, that have continued for decades because ignoring, suppressing and silencing is easier than the alternative.

Strong disagree. The CoC, by design, creates more conflict than it resolves.

You have now painted a target on your project, every activist that finds your CoC in non-compliance now has:

1) a means to proposition your submission

2) a cudgel to bang you with should you reject #1

A far saner solution is to ban CoC and those who request a CoC. The CoC then becomes “don’t request a CoC”. Tolerance paradox in action.


Sounds like speculation. Every community needs rules, and those can be either tacit or codified. The former way is really pronlematic. Are you opposed to laws at a nation-state level as well?

in general, i believe in the effectiveness of running communities via benevolent dictatorship. a group that has good reputation among the rest of the members, gets to decide how disputes are resolved / who gets silenced, etc., without having to justify themselves against a byzantine set of rules. for many open source projects that hope to be used by the wider world, this governance model is unacceptable though.

Counterexample: Linux, GCC, Python, and practically the entire free software ecosystem from before the current crazy for hall-monitory-y supervision from above.

It is simply demonstrably, factually, clearly not true that a growing community needs the kind of structures that Rust imposed on itself.

It really makes me sad that a certain kind of person these days sees some kind of censorious overlord as essential for the formation of healthy communities.

> There's no shortage of guidance to "stay away from X tech because the community is toxic and non-serious"

A disaffected and loud minority says things like that, and the rest of the world goes right on ignoring them. Zero people in the real world avoided using the Linux kernel because Linus was brusque.


> Zero people in the real world avoided using the Linux kernel because Linus was brusque.

Actually, the best example of a project where the leadership of the project was so toxic as to drive away potential contributors would probably be glibc under Ulrich Drepper, which got so bad that most distributions abandoned glibc for the eglibc fork. (See https://lwn.net/Articles/488847/ for a high-level discussion).


Drepper was an asshole and people eventually routed around him, yes. The system worked. What people forget, too, is that Drepper's problem wasn't just an obnoxious personal style, but a ridiculous level of technical conservativism that led to critical bugs remaining unfixed for years. It was the latter problem that eventually prompted people to fork glibc, not the former.

NetBSD -> OpenBSD

I know very little about NetBSD and am a great fan of OpenBSD.

But Theo is a very horrible person who often attacks people in a personal way for disagreeing with him. I got into a stupid argument with him over fundraising - a subject where I have deep experience - and it was quite bizarre. He had a set of assumptions and disagreeing with them got abuse from him, and some of his minions on the OpenBSD-Misc list, and (I was astonished) abuse in my INBOX from throw away accounts.

What an arsewipe!


And FreeBSD -> DragonflyBSD. Same story.

I mean, I think ReiserFS deserves an honorary mention.

Perhaps no user avoided it (though that seems unlikely), but can't you imagine why some contributors may have avoided it? Wouldn't that lack of potential contributions be a material loss for the project?

Who's to say that more contributors are turned off by Rust-style behavioral micromanagement? It's impossible to prove counterfactuals.

All we can say for sure is that dozens of critical projects in the past reached an amazing level of quality and importance to humanity without tone police lurking in the background and supervising it all.


I do wonder whether there's not some implicit benefit to this kind of management. Is it possible that by dissuading all but the most confident committers the project's contribution team self-selected for stronger devs? That would probably be bad for small OSS projects and good for kernels.

One of the biggest contributors to R's success over the past decade is folks having negative experiences with the Python community, particularly folks who are women, non-white, or come from non-CS background. The R community (and RStudio in particular) has worked hard to be much more inclusive and you can see this clearly reflected in the diversity of users and package authors.

Linux with Linus, who famously had to change his abusive tone? GCC with Richard Stallman, accused of various kinds of sexual misconduct? Python, which felt it necessary to impose a CoC eventually?

Your counter examples are questionable at best.


If “accused” is the worst you could come up with, maybe you shouldn’t spread random accusations so wildly.

Anyway, regarding Richard Stallman and those accusations of “various kinds of sexual misconduct”:

https://sterling-archermedes.github.io/


What random accusations am I "spreading so wildly"? The fact that Stallman is being accused of various kinds of sexual misconduct is a fact. I did not anywhere claim they were true. I'm pointing it out because it makes the points above stand on shakier ground.

The article you shared also fails to defend many of the accusations against Stallman and completely ignores them, for example the "Emacs virgin girl" situation.


Technically, what you did was to insinuate, not directly accuse. Which one is worse?

Since you seem to have a great interest in this, do have any concrete reference to the “Emacs virgin” situation? I have only a vague recollection that Stallman was referring to anyone who had not used Emacs yet as an “Emacs virgin”, and some people took it as meaning some kind of sex thing.

(Any other references to the “many of the accusations against Stallman” that wasn’t referenced in the linked article would also be interesting to see.)


There are so many snowflakes in the tech world right now. Horrible.

But Linux had ~20 million lines of code and billions of installs before Linus' change of tone, so I think it is a good counter example.

> accused of various kinds of sexual misconduct

I don't think this is a fair counter example, he's been accused for expressing personal opinions, on his personal blog.

The accusations led to nothing.

Linus changed his tones just recently, now that he's older and have children, the "previous version" of Linus brought Linux to where it is though.

He's still very harsh when things get highly technical, because he's one of the few people that know at heart what's best for Linux.


Richard Stallman was accused of ""sexual misconduct"" ?

Linux and Python (not aware of GCC) effectively have BDFLs that can just nix anything (hence the "dictator" in BDFL). So these aren't just really comparable.

And they absolutely turn people off. The thing is, as long as it doesn't turn everyone off, it allows the project to move forward, because even with burned bridges, it leaves ownership clear.

Communal decision making, however, does not have that advantage. If both sides of an issue, so to speak, become turned off of one another, you are more likely to have an abandoned project. There are, of course, other advantages (you don't miss generally accepted "good ideas" because of the particular vision of one person, and you can apply community standards to everyone, rather than having to weigh "continued participation in this project that is important to you" vs "dealing with -that- asshole again"), but that is definitely one con.


Yes, which is why Rust has been such a failure.

...I think many people would disagree with you about Linux. And perhaps GCC as well.

Yeah it's comical because Linux has so obviously driven a lot of people away from kernel development. Tech is male-skewed, and OSS more so, but Linux kernel dev is even then still at the far end of the gender disparity spectrum.

> Yeah it's comical because Linux has so obviously driven a lot of people away from kernel development.

I hear this "a lot" very often, but then it seems to be from people who have no real interest in technical work of kernel/OS core development. Linux is not the only way to scratch your itch for interest in low-level system dev. Like, this is just personal experience, but I have heard this on the order of 50-100 times: someone parroting how toxic Linux kernel dev is because of drama they heard -- but then you kind of dig a little bit and see what kinds of software stuff interests them, what do they work on -- probably only once or twice has it been anything embedded, hardware related, close to the metal. I would need compelling evidence to change my opinion that most of the complainers have no interest in the work being done by the community they are complaining about -- and I am fully aware that a number of people have departed Linux development, but we are talking about a tiny number of the thousands of contributors over the years -- you can't please everyone.

The hobby OS, emulation and demo scene is a pretty good indicator for "natural"* gender breakdown. These tend to be tight, tiny communities or often lone wolves working on projects. It is male dominated. This can't be explained by any systemic or community gatekeeping - because there is no system nor any mandatory community for participation or distribution. Nothing prevents anyone from putting their work out there.

* I am not discounting there may be other systemic reasons that set up this condition - but it has to be societal conditions that are in place in early childhood -- something that happens a bit before one considers contributing to the Linux kernel.


Agree completly. I would add that not just they are not interested...they have nowhere near enough skills to do anything in the kernel / os development space

You know nothing about me and are just making wild inference and conjecture.

Are you aware of how many people have been driven away from Rust because of their community? I've never seen people talking about avoiding Linux even 1/10th as much as they talk about avoiding Rust. It's entirely due to the culture; developers don't like a culture in which a programming language needs a multi-member moderation team (who resigns because they can't punish people 100% of the time).

>gender

sex - sure, but gender? we got plenty of females in OSS!


More so in Rust than in many other communities was my perception. Far more trans women per capita in that community than Linux kernel dev.

Still a general underrep of women.

e: Oh I see - your comment wasn't in good faith at all.


>More so in Rust than in many other communities was my perception

not just yours :)


In my personal experience such statements are pretty rare actually.

In my personal experience such statements are actually not rare among specific minorities, and only in spaces between those minorities. They will never be said in a public way, because it makes them targets. I've been pulled aside by fellow minorities and warned against communities I had expressed interest in in the past, always in private in confidential spaces.

But what you're saying is that people will disagree about what communities are "toxic and non-serious". I might think that, e.g. much of the blockchain space easily matches that sort of description, but it would be harder to say whether that's a majority or minority viewpoint.

The fact that people disagree is a reason to not have moderation... why?

Because it's good for people to have and to share diverse opinions. The point of moderation is to prevent fringe elements from ruining something for everyone else, not to enforce homogeneity where consensus has yet to be formed.

I openly advise my students to stay away from posting questions on StackOverflow and ask for help among their peers and teachers. At least until they're able to clearly grasp what the "Minimal Complete Verifiable Example" is, how to minimize code, and how to google problems with slight variations, which are not easy skills.

It's not to say that StackOverflow is generally toxic. It is, though, unusable by beginners, and it's mostly by design. And I don't think there is a good way to communicate this to a beginner whose question has been just closed because it lacks details.


Oh, I think they are not as rare as you think. People are actively deterred from, say, Linux kernel development because of the community.

Yet the kernel is one of the most successful OSS projects of all time. I'm not sure it makes your point very well.

Turns out asshole can make good software!

It's almost as though software development skills aren't correlated with social skills...


Sounds like an argument to keep the feels police out of software dev.

We have significant, documented evidence of assholes producing world changing software.

We can’t do the same for the inverse personality type, can we?

I’d rather have amazing open source free software than the validation of a blue check mark.


> Sounds like an argument to keep the feels police out of software dev.

Not unless you discount the idea that it could be even better software if those people hadn't been turned away...


have you seen a thread discussing OCaml recently?

no, link?

OpenBSD

Have you ever tried learning PHP? Even the people that don’t actively work with it are toxic :P

On average I've found projects with explicit CoC's to be more toxic than those projects without Coc's.

This could be Berkson's paradox (https://en.wikipedia.org/wiki/Berkson%27s_paradox) in action. Larger projects probably have more toxicity than smaller projects and are more likely to have a CoC. The result is that the two factors appear to be correlated even if they are independent variables.

It would be illuminating if you could back that up with examples

We’re almost there, I’ve blacklisted all OSS with CoC from our products/services.

We’re down to the last 2, in house rewrites have replaced the rest with superior performing alternatives.

I would normally support pushing our clean sheet rewrites MIT, but I need a license that prohibits the addition of CoC in all derivative/downstream/forks.

In the mean time I’ll settle for a competitive advantage.


You might find this entertaining

https://github.com/domgetter/NCoC


You don’t use Linux?

> There's no shortage of guidance to "stay away from X tech because the community is toxic and non-serious"

Absolutely, but the remedy is often worse than the illness. Codifying good behavior - and in particular policing language - tends to become a bureaucratic and endless black-hole project that sucks up all energy and resources, no matter the justification. There is no shortage of moralists in this world. A common misconception is that by declaring you are against toxicity, you cannot yourself be toxic. In reality, there is no such silver bullet.

Toxic behavior is either deliberate or unconscious. If you want to be an asshole, there's plenty of room within the guidelines - it thrives within wokeness, meritocracies and BDFL-run projects alike. And if you don't think you're an asshole, not even the best CoC will change your mind. There's no shortcut here, you have to confront people directly with concrete criticism, and allow them to change, or in rare cases remove them.

For instance, Linus toned his style down after realizing the effect it had on people, not from reading the sacred CoC scrolls. In fact, I have never seen or heard anyone who has meaningfully changed their behavior from a CoC.


> avoid reputational damage

In less censored circles, Rust has THE worst reputation of any programming language purely because of this kind of management. The entire reputation of Rust is "that language made by insane leftists... with some memory safety or something". I've never seen any language community with a worse reputation, including JS.


"less censored circles" is a wonderful euphemism for, i assume, some cave full of idiots.

Meanwhile, above ground, JavaScript, Ruby, Haskell, and Scala all have worse reputations than Rust.


> A growing community needs healthy management

Like this person being the executive director? https://archive.fo/f10KK


That person is no longer the (interim) executive director. In fact the Foundation decided to go without anybody filling the post for a couple of months instead of them until they found a permanent replacement - which they did just days ago.

Examples?

EDIT: it's remarkable that there's none, aside of "someone said something"


Rich Hickey specifically said that some Lisp groups were extraordinarily toxic, and it's something he wanted to avoid in Clojure. (I think it was in his HOPL talk).

Also, I would say that help-bash@ and the bash IRC channel are pretty toxic.

By "toxic" I mean that there's just a general culture of negativity, insults, hazing, and assuming the worst. There's definitely a thing where computer nerds try to one-up each other, and highly technical or obscure topics like Lisp and bash tend to bring that out.

I have a memory of comp.lang.c being pretty bad too, but I didn't participate for that long, and this was long ago.

Honestly it's funny to me that people think HN is toxic, because it's not even close to those forums in my mind. (well maybe that's because I almost never read the politics threads on HN, but still)


> Honestly it's funny to me that people think HN is toxic, because it's not even close to those forums in my mind. (well maybe that's because I almost never read the politics threads on HN, but still)

I strongly agree. I was reading the archive of an early infosec group the other day, the culture was extremely hostile. 70% of the posts were insightful technical discussions, the remaining 30% was full of personal attacks and name callings, merely reading those posts made me want to throw my computer out of the window.

I'm not saying HN is great, but to give a sense of scale: on HN, that type of posts would be flagged to death almost immediately.


I think what people sometimes mean when they say "HN is toxic", is raging incompetence paraded with confidence (and getting upvoted), which I've seen many a time here. Similar to reddit.

Infosec seems to have its share of angry people in general. One notable blog you’ll see on here from time to time generally has informative or moderate content, but the comments always seem to be a bunch of pointless shouting at things not really related to the post.

> Rich Hickey specifically said that some Lisp groups were extraordinarily toxic

This is an interesting topic I try to stay away from here, for obvious reasons, but so many lisp communities I’ve seen seem to form around these cult of personalities or have the most, err.. eccentric members. More so than any language I’ve seen. People like to joke about Haskell programmers being cult like, but I’ve been down some really wild rabbit holes with lisp.

Ironically I recall some allegations against Hickey a while back that if true would land him in that category.


Well, as the saying goes...it takes one to know one ;-)

That's interesting, I also came to the conclusion that lisp communities skewed unpleasant. I think it's because they tend to be people (men as it happens) who are older and were around at the time of the original IRC culture, which was quite aggressive / countercultural / unprofessional compared to modern professional standards in tech.

Scala's community has a reputation for toxicity. I don't write Scala, so I don't know how deserved this is, but nevertheless the reputation exists.

I'd say there's a fair amount of public drama but the actual community is pretty chill nowadays i.e. gitter and the like

Hacker News. There's an entire subreddit based off of the comments on here.

I've seen this being said about Elm, OpenBSD, ToxChat

Emacs and Elisp.

I have never seen that on the table to be honest, certainly not on implementation language topics. There was some uncertainty with Java and licencing that I remember, but it is mostly about the issue on how to acquire talent.

People tend to be careful with Rust because it is a relatively young language. Many medium sized business don't have much capacity to experiment but would still try it without too much convincing.

Far more relevant it access to professionals that have experience with the language. That is something that grows very slowly. The JS community is pretty "expressive", but it is still a popular choice because you find a lot of people with experience here. My boss would expect all these nerds to behave badly anyway. I doubt he will ever change his opinion but the next generation might.


I mean with this, the rust evangelical strike force, and the drama around actix-web - I'm not getting great vibes from the rust community.

Absolutely, no. Bureaucracy is not a substitution for being properly socialized and knowing how to interact with colleagues. In an earlier time they called this good breeding.

Setting up little etiquette kangaroo courts with the power to arbitrate who is allowed to remain in the community is just fundamentally alienating.


I used to believe good ideas were self-evident, thus less structure was a good thing. Now however, I'm very conflicted. Those with enough previous influence can remain unchecked and sway the popular interpretations of the language and development.

Remaining small and consistent is still a nobel goal, but new features can be a boon to the community.

What do you do indeed?


>Programming Language authors love to formalize everything

Everything but writing a formal specification for some reason.


There are programming language theorists and practitioners who love writing formal specifications. They are just too busy doing that to author many languages. Formal specs are expensive.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: