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.
> 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.
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.
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.
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:
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.
> 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.
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.
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.
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.
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.
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.
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.
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 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.
You might care to notice that the resignation was announced by Andrew Gallant—more commonly known as BurntSushi[1]—who is one of the most well-respected, talented, and prolific contributors in the wider Rust community. Amongst other things, they are the author of ripgrep[2], the regex[3] crate, and the byteorder[4] crate. They have multiple projects which are amongst the most-downloaded crates[5] in the Rust ecosystem.
One would struggle to find more than a handful of people who have done more "actual work" for Rust than Andrew.
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.
> 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.
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.
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?
> 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.
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?
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.
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".
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
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]
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.
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.
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?
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.
I'm genuinely curious: why should contributors have to endure someone's toxicity if something can be done about it? In professional settings, I've seen colleagues get fired over bad behavior, and not for the lack of competence - and I can safely say the team's morale and productivity went right up each time. I fail to see how this couldn't be applicable to open source projects that wish to do it as well, as you'll typically have to get involved quite a bit with these individuals if you're going to contribute.
And not even just contributors. Users of your project might not want to interact with your team. If I encounter a bug and want to create an issue, but I either see racism within communication, or just overall negativity in comments from members, why would I continue with your project? I could just as easily be subjected to it.
If it's that important to you, it's likely in a professional setting, isn't it? I'd say most CoCs are perfectly reasonable, and you usually have to go out of your way to cross them in a professional software development environment.
> it's likely in a professional setting, isn't it?
Not necessarily!
> usually have to go out of your way to cross them in a professional software development environment
I believe this subthread is about the situation of some example hypothetical person being a user of a project in which there are "bad" things going on (whether or not there is a CoC in place that is being violated).
This user is not the one perpetrating abuse.
Say that user reports some problem and is treated abusively or whatever. Or just learns about that kind of thing going on in the project, and disagrees with it.
So question is, why would that user continue to use such a project.
Well, there is the answer: people depend on stuff in ways that they just can't drop it because of someone's behavior.
> In my eyes someone is allowed to be as hateful as they want as long as they contribute good code.
I would argue that you don't literally mean that - or rather there are situations you could find yourself in that would result in your changing your mind on this.
Although it's possible you're being slightly disingenuous and what you really mean is more "The thing I currently suspect is happening in the Rust team isn't something I would regard as serious". I suspect that's behind at least some of the responses on this thread.
Really disingenuous. Even if you yourself don’t value civility and just being a good human being, a toxic team member may easily cause a net loss of good code, no matter what sort of 10x engineer they are themselves, due to the opportunity costs they incur.
Sounds like a great way to end up with your team consisting of only one person. Not very effective. Do you expect everyone else to just endure that behavior?
Can you explain to me what your definition of snowflake is?
Is it anyone who doesn't agree with the ethos "In my eyes someone is allowed to be as hateful as they want as long as they contribute good code."?
Genuinely asking, as it seems to appear several times throughout this topic and the only thing I can settle on is that it's used as a derogatory term for anyone who cares more about X or Y than the person calling them a snowflake. (Does asking make me a snowflake?)
"Someone who chooses to get offended about what others write or say" would be my working definition. I don't think being offended is a reasonable thing to be, generally.
Yes. People make themselves angry, people choose to take offense. The reasonable thing to do is not allow yourself to be provoked to upset or anger by someone else's communication. People you disagree with are easy to ignore, even if you find their opinions loathsome.
We have a system of law and justice that is designed to prevent people actually visiting harm on eachother. We should draw the (very clear and very sharp) line at doing harmful things, and allow people to say whatever they want.
The alternative we're seeing is an ever-expanding, ever-blurring definition of what is policed as "offensive", stifling innovation and fostering division.
I cannot remember the last time I got offended by an insult. A little bit of stoicism goes a long way. It is up to you whether or not you get offended by an insult. I typically choose self-deprecating humor as a response to insults instead of wasting my energy getting angry.
I can understand this reasoning when it comes to personal insults. I understand it less when it comes to tolerating baiting, which takes time and attention from the original reason (work, fun, etc.) of the social space. Why is being offended by not being able to communicate unreasonable?
I'm also interested in your take in the kind of communication that's intended to falsely undermine your reputation. I guess it's similar to the above example, but it's more personal and threatens group coherence. What's your take on being offended by that?
re: baiting, if you take the bait, it's on you. If you don't think someone is being genuine, you're free to disengage. No one is forcing anyone into a conversation, especially online.
> communication that's intended to falsely undermine your reputation
If a claim is false, that's the most damning thing that can be said about it. Whether it's "offensive" (or whether you're offended) or not is irrelevant.
I see where we differ now: I've experienced that when you are being barraged with mud, some will usually stick, with the exception of maybe groups of close friends.
As such, I don't mean that you are the one who takes the bait, but other members of the group. Bikeshedding is so popular it even has a special name, and it affects the performance of the group relative to the original goal even if you're not the one who took the bait.
So while I agree that baiting/insulting it's not something to be offended about, I think the response should be effectively the same as if it was.
I did not know that insults are capable of doing that. If the insult is based on something accurate, then what is wrong with it? Just realize it is based on reality and improve. If it is not accurate, then why give a damn?
This was added within the last 3 or so years as the result of an intentional social struggle to put a CoC on the kernel. It remains to be seen what the net effect of this on kernel development will be.
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?
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.
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.
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 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.
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.
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.
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.
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 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.
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.
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.
> 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.
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.
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.
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."
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.
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.
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?
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
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.
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).
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.
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).
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.
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.
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.
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.
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.
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.
These "internet activists" you spend so much effort maligning are simply reminding you that there is a human being on the other side of that screen.
I'm not inside the Linux developers' world, but from the outside it seems like a much healthier, more vibrant place since Linus realized that he works with human beings.
> These "internet activists" you spend so much effort maligning are simply reminding you that there is a human being on the other side of that screen.
Actually, primarily they're reminding me that there's a human being on the other side of the screen watching everything I do in case I fuck up. How this is supposed to make anyone want to participate is a mystery to me.
edit: The weird thing to me is that these people are so hyper-vigilant to the damage bad behavior can do, and utterly blind to the idea that their own behavior can also be damaging. If I ever read a sentence like "we know that overmoderation and tone-policing can create toxic communities, and we're watching out for that" from a moderation team, I will know that this is a community that I can trust to be administered in an even-handed and fair manner. So far I have seen this once.
Well, the question is rather- what is a "fuck up" to them?
And to that- who knows? Certainly the point of a CoC is supposed to be to codify this, but I believe experience shows that its interpretation tends to be expansive, when the wording is not already expansive to begin with.
At the end of the day, events like Curtis Yarvin, a person who has never harmed a fly, almost getting banned from Lambdaconf over "safety" concerns, demonstrate that the fuck-up may just be having a political difference of opinion with the group in question.
(Analogously, and I say this as somebody who would vote Dems every time if they lived in the US, a moderation team that included at least one Trump voter would also assuage such concerns. Consider it a commitment to diversity.)
edit: To be clear, I am not asking for anything resembling quotas; just any demonstration of the ability of the team to coexist with a person they have serious ideological disagreements with.
I wasn't familiar with Curtis Yarvin, but in looking him up, you can't be serious, right?
>Yarvin's online writings, many under his pseudonym Mencius Moldbug, convey blatantly racist views. He expresses the belief that white people are genetically endowed with higher IQs than black people. He has suggested race may determine whether individuals are better suited for slavery, and his writing has been interpreted as supportive of the institution of slavery.
Curtis Yarvin is a bellwether - the sort of person that any group that starts excluding people for ideological disagreements, would probably exclude first precisely because his position is so problematic. So any group that accepts his technical contribution can obviously be trusted to tolerate any less-severe ideological disagreement. Conversely, any group that doesn't, especially when they have to make up nonexistent concerns to do it because their rules didn't cover this "obvious" reason to kick someone out and couldn't be hastily adjusted, must be viewed with caution.
I personally don't hold any beliefs nearly as objectionable as that. But I do hold objectionable beliefs - as I believe any halfway interesting person does. And those who don't, probably will eventually. Just stand by your convictions and give it time.
> Call me crazy, but I believe that you don't have to actively champion and invite openly racist people to conferences to show that you tolerate difference of opinion.
Sure you don't have to, but if you do, it's a hell of a signal. (At any rate, Curtis Yarvin was invited for his semi-esoteric functional-based distributed operating platform, Urbit.)
> If you're protecting personnel, even after a number of others in your community have shown disagreement with the person's actions (and protections afterwards), just admit you agree with those thoughts.
Sorry, I don't. Of course, you'll believe that I do anyway, and that's fine. I do think it's a bit sad that you think that the only reason someone could want somebody to be included, is because they were your ideological compatriots.
In fact, the only reason I want anyone to be included in a conference is if they have contributions to the conference's topic.
No, I think someone should be *excluded* from talking at a conference because they literally write Eugenics theory, regardless of the brackets, semicolons and spaces they write in a text editor.
It sounds like we just have a difference in moral standards.
I just disagree that standing in his presence is a matter of safety for anyone. It's possible to hold abhorrent views and still be a useful contributor.
Yes? They might have other useful ideas or opinions that I may benefit from being exposed to. People are multidimensional.
If there is a conference being organized about some technology, I'd like to see speakers who have the most to contribute, on that merit only. I couldn't care less if they march around with armbands on in their spare time. I'm suggesting that more people learn to compartmentalize.
To me, if they can keep it to themselves, they can believe whatever they want. Up to and including that I shouldn't have been born, though I may draw a line at believing I should be killed, depending on how mentally stable I believe them to be.
>I am not asking for anything resembling quotas; just any demonstration of the ability of the team to coexist with a person they have serious ideological disagreements with.
That would be nice... unfortunately, filter bubbles are such that it's hard for most people just to locate a reasonable person who has serious ideological disagreements with them. The current polarisation didn't happen in a vacuum.
Right, and the suggestion is that this human being (and all the other ones) should be responsible for managing their own emotional state, instead of shifting the burden onto everyone else.
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?
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.)
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.
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
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).
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
They agreed to the code of conduct by agreeing to be members. Also, regardless of the lack of details, they clearly want the core team to be held to the same standards as every other Rust team.
Just because I put a brick through your window with template EULA language stating you accept and hereby authorize me to have hurled the brick through your window and that you, the recipient, now indemnify me, the thrower from any damages caused in the process of the message on said brick making it's way to you for recipient, does not mean you can go around chucking bricks through folks' windows. Despite what the tech sector really, really, REALLY hopes people never become irritated enough to actually bother to read up and hold them accountable to.
Meeting of the minds, people. It means something damnit. Just because a bunch of you shoved some boilerplate in the repo doesn't make it binding, and the fact you did, like it or not, alienates a bunch of people who would otherwise be more than happy to extend a helping hand if the extent of the relationship was only the proposed contribution.
t. someone very selective and wary of contractual language when they can afford to be
> 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.
Isn't that a kind of scorched earth statement? I read it as "we will be discreet and don't believe anything anybody tells you in the future...instead assume all your worst fears are true".
I feel it's a bit of a tautology, the fact that they're resigning already clearly communicates there's an irreconcilable difference between the mod team and the core team. If the core team comes with an explanation that would make light of the situation surely the new mod team would be skeptical.
That said, there is still a bit of a game left to be played. The mod team just played their trump card, by instantly making the matter super public. But by keeping the specifics close to the chest they both keep their integrity and they give the next mod team some leverage for their interaction with the core team to resolve this situation.
It's really good btw that they're keeping the specifics private. Having someone publicly lynched is never a good situation, it's probably something that's offensive to a group of people, but the person(s) who caused offence probably have no bad intentions. It's hard running an organisation with a diverse group of people. You'll never get everyone to settle on the same moral values so it's inevitable that you'll get someone who is unapologetic about some value they hold.
Sometimes they resign when they find out that they can't get others fired.
I don't know whether that fits in this case. I'm inclined to think not; I suspect that those who freak out over trivialities, try to get others fired, find out that they can't, and then resign, tend to have a public hissy fit when they resign. I'm not sure that what the Rust Moderation Team did counts; they seem to be trying to not air dirty laundry (or what they perceive to be dirty).
"by keeping the specifics close to the chest they both keep their integrity"
Odd code of honour there. They've made a lot of dramatic insinuations about other Rust contributors, basically asserted that they're all bad people, and provided no detail. That's the opposite of integrity.
No, they've only said that "something happened". That could mean as little as "one person did something". What they're accusing the rest of the core team of is not being a part of it, nor even necessarily of explicitly condoning it -- just of not explicitly doing, or allowing the moderation team to do, something about it. That may be bad enough, but IMO nowhere near as "dramatic" as "assert[ing] that they're all bad people".
"We're not going to say what, specifically, one or more Core Team members are being held unaccountable for. If the Core Team does say what, specifically, we aren't necessarily going to respond. Don't take our non-response as an endorsement that this is what it's about."
It's more them saying be skeptical of anything the accused says about the situation, which is common sense in that the "wrongdoer" will more than likely spin the story to save face. Unlike a court of law, they're under no oath.
They may make a statement about the situation if the core team decides to release details on the situation, but they don't want to be the first to do so, so they're simply saying be skeptical if the core team speaks out because it may not be the whole story.
Well, obviously, but that's why you should be skeptical of both sides. It's just that the resigned moderation team aren't saying anything. I'd expect the core team to also urge people to be skeptical if the former moderation team do speak out about the situation.
I'm not saying who is right or wrong. I'm just responding to the parent comment because I think they're extrapolating too much from the statement.
We're developers, and many use Rust (though organizational politics can effect many other projects as well, how it plays out here could affect other situations etc) so in one way or another care very much about if the project is being run effectively, which side to support in internal conflict so as to ensure the project keeps being run effectively etc.
Proprietary software has a lot of problems and open source was a good response to them, but it's notable that proprietary isn't as prone to the 'middle school' problem. When money is involved, there's more alignment.
Without knowing details, I can say from experience that those who feel they are the most righteous are often the most wrong. I’ve been on both sides of this.
If this has to be aired publicly, then we need to be able to objectively assess. Otherwise, I’m reading this as ‘we don’t get along with those guys and gals on the core team and vice versa’, which is, fine, it’s just humans not getting along.
Which reminds me, I don’t get along with some team members either. I want to write an email just like this, a veritable ‘fuck off, you stink”. Feels good. Now what?
Move along everyone, we’re all adults after all (right?).
Not really, the mod-teams grievance is with the structure (and accountability) of the rust organisation (in particular the core-team). Likely they were triggered by a specific instance, but we can assess the problems with accountability, e.g. the power of the core-team to ignore rules that apply to everyone else quite objectively by looking at the power structures of the organisation.
I think if you want to highlight problems with a process/structure it is much better not to get into specifics of one instance. This is what the (former) mod-team is doing.
I'd rather say that a specific very annoying type of wrong people feels righteous, for reasons that range from psychotic entitlement to not understanding what they are doing. Right people often feel righteous for valid reasons.
it's very similar to working in a corporation and seeing someone get fired. the company is bound by legal concerns to not reveal why the person was fired, which leaves everyone else wondering if the person had done something fireable or if the company was playing politics with power.
i've heard netflix does things a bit differently. when people are asked to leave, their manager sends an email out to everyone explaining exactly why that person was asked to leave. i assume their generous severance package contains a legal release for netflix to be able to do that.
> the company is bound by legal concerns to not reveal why the person was fired
I think this is a fairly common misconception. While you might sign an anti disparagement agreement when you were hired, those tend to be one-way and designed to protect the company. And the bar to prove a defamation case is extremely high.
AIUI, most employers simply do not disclose details on firings as a matter of policy, not law.
You're correct in that there is no law saying that employers are prohibited from disclosing why a person was fired. But the policies are a result of laws that could open them up to legal action if they were to disclose any specifics. However unlikely that legal action may be, and probably even more unlikely to succeed, they still gain nothing from any such disclosures so it makes perfect sense to prohibit them.
Exactly. Any such disclosure gives a foothold for legal action that could drag on for a long time and cost a fortune. Even if you win, you lose, so why take that risk?
Employers airing dirty laundry is way worse for morale. Typically the people who work in close proximity have a good idea of why their colleague may have been fired, or can reach out to them privately to get details. If the fired employee doesn't want to talk about it, it's presumably something private, and the employer probably shouldn't either.
> AIUI, most employers simply do not disclose details on firings as a matter of policy, not law.
Note that this isn't true in much of Europe, where in many countries firing someone beyond their probationary period requires due cause. I kinda suspect this is largely a function of at-will employment?
It's not a legal requirement, yes, but any competent HR person or attorney will tell you publicly telling everyone in a company or on a team why someone was fired is a huge liability and will almost certainly result in a lawsuit after it happens a couple times.
It's overwhelmingly likely that the person did something that was fireable, even in the big bad, limited employee rights USA.
At the same time, professional discretion is the norm and so you might not know from the written/spoken language if someone was let go because of a specific acute incident or a pattern of under-performance. (Except that people usually know who the chronic under-performers are, so when one is let go, you tend to assume it was performance-related and if someone thought to be a high-performer is let go, you tend to assume a non-performance cause.)
"Assume all your worst fears are true" is substantially different in meaning from "exercise skepticism around public statements by the Core Team." I understand your reading, but I don't think it's warranted by the actual public announcement here.
That's a naïve reading. They are dragging more into the public sphere than necessary to raise their grievances.
They could have kept the statement confined to disagreement with the government structure. Leave it ambiguous between whether it was a theoretical weakness in the structure, or a practical one where they already experienced the inability to censure.
People like goss. Wagging your eyebrows to imply something definitely did happen - but you're too classy to release details - is not a insipid act.
The mod team is in a difficult position and are trying to thread a needle.
* They actions they have taken have publicly-visible consequences, so they must publicly acknowledge it
* They want to be respectful, and so minimize the amount of information they make public
* They believe the Core team acts in bad faith. So whatever public statement they make, they must anticipate being attacked for it and pre-emptively defend themselves.
That's a difficult set of objectives to try to meet simultaneously. I'm going to choose to support they way they've handled it, even if I don't 100% agree with it, because I don't think a perfect solution is possible.
> They could have kept the statement confined to disagreement with the government structure. Leave it ambiguous between whether it was a theoretical weakness in the structure, or a practical one.
Nobody resigns over a theoretical flaw in the governance structure. It’s only when it starts becoming a problem that people do so.
They are dragging more into the public sphere than necessary
That's a bold claim. For you to accurately make that claim, you'd need to know every other piece of the story that lead to this point and lead them to feel that this public statement was their only remaining choice.
I was replying to someone who said the content of the resignation was a refusal to drag drama into the public. I did not say dragging it into public was a bad tactic for accomplishing their goals.
>you'd need to know every other piece of the story that lead to this point and lead them to feel that this public statement was their only remaining choice.
No I wouldn't. I will stand by my claim that they said more than necessary to raise the structural issues they perceive in Rust's governance. They very well may need to say more than that - or even more than they did say - to see their desired changes to the governance system enacted. Not what I was responding to.
Ironically, that's exactly what the moderation team seems to insinuate with their "extreme skepticism" claim.
"You don't know the story, we won't tell any of the events leading up to this point, but you better be sure that these people on the core team are wrong!"
I wholeheartedly agree that "don't trust XYZ, they'll probably lie, but I can't tell you any more about it" is... very non-ideal.
There are some situations in life where there just aren't any good choices. It's possible that this may have been one of them.
What would you do if you felt that you had to walk away from a bad situation on a public project, and had strong reason to believe that the other party would attempt to publicly misrepresent the situation?
You could remain silent, but we're talking about the court of public opinion here and we know silence is often interpreted as guilt, or at least irresponsibility. It would also allow the other party to continue creating this "bad situation" without, at the least, giving future moderators some warning. Likely, the mod team would have faced similar criticism had they simply walked away silently.
Presumably, the members of the mod team are interested in maintaining their own reputations and would like to continue working in this field.
It’s more of a “let’s allude to problematic behavior, without actually explaining it, so we can fuel a maximal amount of speculation, and also let’s throw in some hot-button, culture wars issues, just to spice up the discussion”
I mean, I agree that their intentions were probably more like what you wrote, but the resulting effect is far worse than if some shitty behavior from someone in the rust core team had become public knowledge…
The fact that the moderation team didn't have the power to moderate the core team is public, as it needs to be if that is going to change. The actual moderation issues that arose from that have remained private, which is probably for the best, because the entire point of moderation is to not try people in the court of public opinion.
I'm pretty sure you can resign with a lot less "drama", for the lack of a better word. Simply make the PR remove people from the moderators list and say "We don't want to be moderators anymore", but instead they give clues to what could have happen for them to take this action.
I guess you can say that their action was "semi-public". It wasn't trying to be completely private, and neither completely public, but somewhere in-between.
>I'm pretty sure you can resign with a lot less "drama"
I am not sure you can, unless you play the politician bit and lie about "wanting to spend more time with family" or "health reasons".
If they resigned without any statement, people would have noticed as well, and speculation and gossiping would be still rampant, if not more rampant, because it's not every day that the entire Rust moderation team resigns.
They are between a rock and a hard place, if their objective really was to avoid public drama. Give too little detail and you're entirely at the mercy of speculation and maybe whatever the opposing party puts out (without other people even knowing who that opposing party is). Give too much information and you may irrevocably hurt people (like victims, or even the accused when a mob comes for them) or the community as a whole.
But if you just say "we don't want to be moderators anymore" nothing would change would it? The whole point of the statement is that the mod-team believes something in the organisational structure needs to change.
I would explain what went wrong. It's clear that their organizational suggestions were prompted by a member of the core team doing something they consider terribly wrong - how can it be so bad the Rust community has to know about it yet not bad enough that the community needs to know what it was?
The problem wasn't saying too much, it's saying too little. A resignation is supposed to be a message. The appropriate thing is to make that message clear and professional. It can be discrete without innuendo.
Drama has already been dragged out. Now people are left to speculate and accuse. This thing from 4 years ago has been dug up, for example: https://archive.fo/f10KK and I can see it being the basis of some of those speculations.
> we refuse to drag this drama out into the public sphere"
I genuinely can’t think of a more dramatic way to drag this into the public sphere than saying “we all quit due to unspecified violations of the vague code of conduct - go make your best guesses what those were”
Why are users supposed to exercise skepticism about anything the core team says, without any information from the other side so that we may judge for ourselves where our skepticism is warranted?
I read it as they warn people to believe the core team specifically, not the whole Rust organization, as the reason they are leaving is because of the actions from individuals in the core team (or lack of thereof).
It's not even this, it's only "believe the core Team wrt. this specific situation" as well as a implicit "we do not believe the core Team is suited for making decisions about the personnel of the new Moderation Team Members".
Through it also implies there is at least one Person on the core Team which they are afraid will abuse their "Let's keep past thinks in the past." approach to twist the truth.
Pointing out some specific things is hard as it's most likely not one specific thing but many small things plus some "that's enough" bigger thing(s) and because it likely has various negative effects including:
-people focusing on that specific thing, instead of the general problem (unaccountability)
-people overreacting, e.g. starting a witch hunt with serve negative effects for the community
- ... (other more vague/implicit things, like leaking of private information)
Did you provide a datestamped list of incidents that lead to your decision to quit?
Or were you, by chance, slightly more vague and provide something along the lines of:
"The culture/fit/hours/goals/growth do not align with mine so I am resigning."?
I've always written out what specific issues I had that led me to resign. If you don't say anything, nothing changes. A resignation letter is a professional curtesy, the point is to provide useful, professional information. Of course in some instances there were personal factors that influenced my decision, and I didn't list those out in detail, but I let them know that those were issues on my end that the employer didn't need to address. There's no need to beat a dead horse and bring up every single grievance, and you can be diplomatic, but if an issue is bad enough to warrant resignation, it really should be mentioned in the resignation letter.
I'd certainly never insinuate that my employer had done something wrong but refuse to clarify.
>I'd certainly never insinuate that my employer had done something wrong but refuse to clarify.
I suppose we're of different opinion, as I considered the resignation letter to have enough clarity to the intended recipients to be acceptable. They didn't say "I quit, the end". They pointed at the specific areas of issue (accountability, structure) of which the core team is likely well aware of the minutiae.
Just because it wasn't explained incident by incident to the public does not mean the "employer" (or, in this case, core team) did not understand the message.
I would wager that incidents were brought up, not addressed (or addressed as a WNF), escalated, then resulted in this resignation. The people relevant to each stage will be familiar with each stage, and should hopefully be able to follow the progression.
The public does not need to be privy to each and every individual incident, as much as everyone would like to butter their popcorn.
They dropped a pretty beefy bombshell in the last paragraph that there were issues beyond accountability that they refuse to disclose. I'm absolutely certain that the core team has a good idea what they are talking about, the problem is this is a public letter, the intended audience is everyone, and they specifically attack the core team's credibility.
When I resign from a job, I send my resignation to my employer in private. I wouldn't put anything in it that I'm not comfortable with becoming public, and if they wish to share what I wrote that's fine, but the purpose of being discreet is to leave the level of disclosure up to the other party's discretion. You don't send a company wide email saying "management knows what they did, don't believe a word they say, I'm out, peace!"
>is this is a public letter, the intended audience is everyone
Just because something is public does not mean the intended audience is also everyone. Something can be intended for a subset of people, but broadly published. But I think this has been hashed out somewhere else in the thread.
I think "management knows what they did, don't believe a word they say, I'm out, peace!" is a bit of a disingenuous reading of the letter, but you have a valid point about the last paragraph and I'll walk back what I said a little bit.
That's one of the dictionary definitions. That's not how it's used in everyday parlance however. It's usually used to mean harassment, usually of a group.
> To harass or punish in a manner designed to injure, grieve, or afflict
At this point I think we might just be talking past each other, but I fail to see how this resignation letter meets that definition either. I don't see the letter as harassment to the core team. It also doesn't strike me as a letter designed to injure or grieve.
Semantics aside, the letter may not give enough information to you, but it gives enough information that anyone privy to the internal team dynamics will understand the underlying issues and the logical progression of events that lead to the resignation.
I think Rust is a great programming language, but to be honest all this drama discourages me from using it as much.
I worry about whether using the language will become a political statement. I worry whether people who can't get along are making the best decisions for the language. And I worry whether a total team meltdown will cause it to become defunct or forked at some point.
As a rust user I really don't care at all about this stuff. Rust is bigger than any of these teams now, and it has been for a few years. I have a lot of confidence that the language will continue forward in a healthy way, and that governance issues will ultimately smooth out.
I only care insofar as I have been a part of the rust community for 6 years or so, and I care about others in the community.
> I think Rust is a great programming language, but to be honest all this drama discourages me from using it as much.
It has little to do with using the language.
Also I doubt there is more drama in Rust then in Python, Ruby or similar. It's just that in recent years everything rust get always a lot of attention.
There is also not just "the rust Team" there are many independent working Teams, as well as a foundation. I don't think it becoming de-functional or fork-splintered is something you have to worry about.
Rust overall has a nice and welcoming community. If you want to get an impression, look at the "help" section on https://users.rust-lang.org/. I'm a (currently inactive) member of the crates.io team, and haven't experienced any drama so far.
It's an excellent question, and I would like to know as well.
The big question is whether the Moderation Team is formally appointed by the Rust Foundation. If that's the case, or if it becomes the case in the future, then it depends under which governance provisions the team's writ is created. It could be that the team is created by an act of the board of directors, and then either made accountable to the board itself, or to a specific officer or some other entity. The composition of the team could be left to an officer, or it could be that adding a member requires board action. But I'm speculating here.
Makes me wonder if it's a "who's watching the watchers" situation.
Once, in my fraternity, someone was unhappy with something. (Politics, basically.) They proposed an entirely new board to watch the existing elected executive council. Basically all of the brotherhood would have been involved in some form of administration and oversight.
At this point, one of our more politically knowledgeable brothers laughed, and said, "But who's watching the watchers." The movement quickly failed.
Because it effectively confirms that the mod team wanted to be able to set and enforce CoC rules on the core team. If the core team can set CoC rules they can't effectively be moderated since they can change the rules.
So, basically, it seems that the most common speculation is the following:
While one might have suspected that the Rust moderation team were people with "progressive/SJW" leanings themselves, in fact what happened is that someone on the core team with radical "progressive/SJW" leanings violated the relevant codes of conduct sufficiently that when the core team denied the moderation team their right to take action against the infringer, the moderation team were so pissed off that they resigned.
In light of that it's tempting to wonder whether it's a bit of a sign of the times -- after the last few years of increasingly absurd and ascendant progressive positioning, the adults in the world finally not being able to take the nonsense from progressives any longer and putting their feet down.
In this case, this a moderation of the community of human beings developing the rust compiler and its eco-system.
This is a team of human beings, who are going to have human interactions - tensions are bound to arise, and rules / traditions / taboos will develop to handle / resolve / hide them.
The Rust community seems to be having debates about those rules - not being part of the community, and not knowing anything about the situation, I have to brush it up as "someone else drama."
I suppose you can compare it to either the human interaction in the team of human beings developing `clang` (no idea how this is organized, or wether it has public politics / drama) ; and the C++ ISO community (which I'm pretty sure has loooooots of drama, but keeps it corporate and private.)
It absolutely does not, according to /r/cpp. There have been disputes that nearly led to physical violence, racial slurs, and more. It's just all more "private" by nature of happening in conference rooms and private mailing lists.
People tend to behave better in in-person meetings and on conference calls than on the internet in general. The Penny Arcade comic was too optimistic about the conditions for virtual communities to break down.
Does the C++ core committee have central forums for public discussion of features or is it exclusively a design-by-committee thing with mostly closed-door meetings?
I believe it has both. As far as I know, there are public discussions taken as advisory. Then the actual standards are written in a design-by-committee process. I believe those design meetings have public minutes, but participation requires being a member of the standards committee. I believer membership of the committee is possible through sponsorship with some seats being reserved for community members with high standing. How those seats are filled exactly I do not know.
It has a five-member "Directions Committee", vacancies filled by invitation. The group's minutes are not public, but they have no authority beyond their persuasiveness. The members are there because they were already respected.
Which meetings? Some are more closed door than others. The big committee meetings are open door, anyone can come (pre covid). There are official ISO votes where you need to have your countries' blessing to vote (one vote per country), but most votes are just straw polls and anyone who shows up can vote.
There are also core teams that are closed door. And sub committees, some of which are more welcoming of outsiders than others. In the end though, if you submit a paper the relevant committee will read it and then invite you to come talk about it (at your expense to get there, but they will find a sponsor if needed).
Sure it does, just not one centralized one. LLVM and GCC are very actively maintained and both main teams have many active C++ committee members. Unless you want to split hairs and argue semantics, they are the closest thing to a day-to-day development team and are quite underappreciated if you ask me.
I appreciate them but that's also the difference between Rust and C++ - the implementations are separable from the language itself. GCC is not C++ and vice versa.
Are you serious? Do you know anything about the Rust community and ecosystem? The lead author of the resignation post is BurntSushi (Andrew Gallant). He is a systems engineer at Salesforce and a long-time technical and social contributor to Rust. He has taken the lead on the big parsers for Rust, many of which are still in his personal GitHub namespace. ripgrep has 28k stars, for example.
Things are happening behind closed doors in Rust's leadership. First there was a post from Steve Klabnik, a member from the Core team, about how Amazon is taking too much power in the Rust leadership (discussed here https://news.ycombinator.com/item?id=28513130). Then that post, that seems against the Core team. I would appreciate some transparency and clarity about what's happening. Lots of people are currently wonder about whether or not to invest in Rust, me included. Stuff like that is a clear negative signal for me.
I did see it, however it seems to be just speculation about what is happening. I don't want to base all my opinion on that. Some of these are rather heavy accusations, like the nepotism between Steve Klabnik and Ashley Williams, or that Steve Klabnik smeared Amazon because they didn't give Ashley Williams a job. I don't want to give them weight when the only source seems to be a pseudonymous post.
The poster there actually worked on the Rust project and did more than Ashley Williams, at least on the technical side. I even noticed their "absence" (or lower involvement) earlier this year and was wondering if they're okay.
As for Steve's rant [1], it was weirdly guided against the "Rustacean principles" (which are totally harmless [2]), but happened right after Ashley's interim director contract was not extended.
Actually, on the HN post back then, Steve complained more about how Amazon didn't give her the job, than anything else.
> Actually, on the HN post back then, Steve complained more about how Amazon didn't give her the job, than anything else.
Where did Steve mention Ashley not getting a job at Amazon? I remember reading through that thread but I don't remember Steve mentioning that. Today is the first I'm hearing of it.
I feel like there is always drama or issues surrounding the governance of Rust. It has definitely made me wary to adopt it as a long-term language. Maybe I have recency bias or something.
This person being a prominent part of the Rust community definitely does not make me want to engage with it and does make me wary of the stability of the language as well: https://archive.fo/f10KK
Yeah I have the same impression. Other languages don't seem to have the same drama issues. Rust came out of Mozilla, which is super steeped in SF social justice culture (see the antics of their CEO). It seems like that culture was carried into Rust.
> Mozilla, which is super steeped in SF social justice culture (see the antics of their CEO)
Who do you mean? The only Mozilla CEO I can remember being involved in any controversy was Brendan Eich, and that controversy was over his funding a campaign against gay marriage. I can hardly imagine calling that 'social justice culture'. (I'm hoping this comment doesn't summon him, like the last time I mentioned him on here: https://news.ycombinator.com/item?id=28789197)
Mitchell Baker has repeatedly embarrassed Mozilla and failed in almost every way a CEO can fail. She is very obviously uninterested in Firefox and sees it just as a way to further her own influence amongst the Washington set she wishes she was really a part of. Mozilla not only has a "social justice" culture but openly talks about it all the time: https://blog.mozilla.org/en/mozilla/leadership/mozilla-racia...
"We granted 33% of Mozilla Foundation funds to black-led tech and social justice initiatives. Unfortunately, we fell short of our 40% target."
The Mozilla Foundation is meant to be funding Firefox. That is its purpose. Instead it is using money raised for that purpose to perpetuate SJW culture and overt racism against white people.
The type of insidious and dishonourable mind games the Rust moderation team are playing here is exactly the sort of thing I've come to expect from Mozilla-associated projects. The apologetics for it in this thread are just wrong. My weapon of choice is Kotlin, made by Russians. Guess what: there's no moderation team, the community is fine and in the 10 years the project has existed I recall exactly zero community related dramas. None. Zero. Nada. This sort of thing isn't normal for programming languages and people trying to claim it is are wrong: it's normal for languages controlled by a very specific kind of person in a very specific region and subculture of America.
In contrast, Brendan Eich kept his politics private and actually cared about Firefox as a product and technology.
Ah, I'm sorry, I hadn't heard of this. I don't necessarily agree with your political opinions, but I agree that it feels inappropriate to spend Mozilla Foundation funds (which I gather are 98% donated money) on anything other than the Mozilla projects which people obviously expect their money to go to.
Fair enough, I didn't mean to be too nasty. He has a right to his opinions, even if I consider them by turns a menace to society (in the vax case) and not terribly enlightened (in the gay marriage case, considering I'm gay myself). And I obviously respect the guy tremendously for his life's work and contributions to the world, which are far more than my own.
I was just looking at it through a slightly different frame since he's a (relatively) public figure. It's one thing to tag your Facebook acquaintance in a post and have them respond, it's another to make an offhand, slightly pejorative reference to Beyoncé and then see that Beyoncé herself sent you an angry reply. It's certainly his right, but it's a bit unexpected, and I don't think 'summon' was a particularly bad word for it.
But I suppose this is a tech forum, and Eich is not Beyoncé, so it's a bit hazy.
I'm not sure what the real problem is, but we live in a economical system that have a tendency to hijack governance of things that are important to 'them' (whoever the contextual them are) and re-purpose it's goals and direction
working as a effective power-grab strategy.
You can see this happening with browsers for instance, where the companies now are the ones who define the standards with things that are important to them, like DRM or showing ads, embellishing the pill with things nerds and hackers also like, where once this governance where in the hands of Tim-Berners-Lee et al.
And that's because we are talking about technologies that born more free of corporation oversight, which is the minority.. (Think Java first with Sun and now with Oracle for instance)
This Rust thing is just because powerful corporations are adopting it, and defining board members, so they can define more the direction of the platform and the technology.
For those corporations corrupt board members that know who owns them and what interests they should defend are more important than the personal character of that board member..
It's always like this and it will always be like this. Capitalism is a amoral system and it will turn everything it touch into its own image..
Until we don't stop and fix the root cause of the system that is corrupting everything that we value its like thinking you can stop a ocean wave by resisting it while on front of it.
Note: I'm not advocating to just destroying capitalism as a solution, but to acknowledge that this is actually systemic and happen all over and instead to try to fix the specific problem caused by it, we should get back some steps and try to fix the problem, which is systemic, for everything while preventing it from happening all over again in the future.
I disagree, it's the opposite - capitalism is the fix and the lack of it is the cause. The problem is the way Rust is run and the sort of people who were invited into it in the early days.
Consider Kotlin. It originates from one large company - JetBrains have over 1000 employees and the Kotlin team alone has over 100 people on it - and has been adopted by another much larger company (Google) as an official language. There are no dramas. Why, because the Russians are mission focused and don't feel any need to constantly virtue signal.
Consider Swift. It originates from a large company. I don't remember reading about any political dramas in the Swift world. That's because Apple are mission focused.
Now look at Node or Rust. Both have attempted to build some sort of non-corporate governance system, they're based out of the Bay Area, and all of them seem to be absolutely beset by internal conflicts and strife.
That's frequently the nature of "community" projects. They're based in a particular idealism wherein authority is a patchable bug and direct democracy can scale infinitely.
In reality, they are just free-for-all power struggles. What starts out as anarchic fun and inclusivity among ~1-100 like-minded people scales into dysfunctional sectarianism.
What a strange way of looking at it. At any functioning company, toxic employees get fired because the cost of them pushing out other employees is usually higher than the cost of firing them. Open source projects do not hire and fire people but do have the ability to censure toxic contributors.
I know nothing about this particular case, but the general idea of moderating contributors to a project is not wacky as you seem to believe and predates the existence of distributed open source development.
Except in those situations you never weight the amount of people you lose by adding a significant level of "cultural oversight" to a project. I actively avoid projects that spend a lot of time talking about "inclusivity" because to me it's a symptom of a (ironically) toxic environment full of people looking for drama (I am an ethnic and sexual minority myself in case someone wants to throw privilege in my face).
The end result is that you replace one group of people with another group of people, you push away some to gain some. Except people like myself are rarely mentioned when there is a discussion about toxic environments.
> I actively avoid projects that spend a lot of time talking about "inclusivity" because to me it's a symptom of a (ironically) toxic environment full of people looking for drama
100%. I do the exact same thing, for the exact same reasons.
If you see a code of conduct that reads like a political manifesto, that's a red flag, regardless of the particulars of the politics expressed.
That pr is less ominous than you're making it sound. These are temporary moderators who were on a a different rust moderation team -- https://github.com/rust-lang/team/pull/672
I love Rust the language, and the community is generally good, but for whatever reason modern identity politics has always been looming around its key members. Maybe just because it spun out of Mozilla and the Brendan Eich debacle, who knows.
I'm not seeing any connection between the linked discussions and identity politics, and I'm certainly not seeing any connection with Brendan Eich. Hopefully not every thread that involves reference to a CoC has to automatically turn in to a grievance bin for people who have a bone to pick with identity politics.
It's actually the opposite. In a repeat of what happened previously in the NPM community, people are asking for the CoC to actually be enforced _because of_ identity politics, rather than associating CoCs with identity politics.
Going around saying things like "Kill all men" is just about as obvious as a CoC violation can get.
Additionally, having members of the same governance body that are romantically involved probably isn't very effective strategically.
"The core team refused to kick out a misandrist member" would lead to a lot of drama if they said it publicly. If that is why they are quitting then it makes sense that they refused to say anything about it.
It's not like she would be the first or the only team member with rather controversial political views. As long as these views don't meaningfully impact her work on Rust, why shouldn't she be on the team? Why can't we just learn to be more tolerant of dissenting views?
Well, then there's the other accusation: that she applied for a job at Amazon and was rejected and since then her partner, also a part of the core team, has been publicly negative about the relationship between Rust and Amazon (https://news.ycombinator.com/item?id=28513130)
There would seem to be a massive conflict of interest there, if true.
> It's not like she would be the first or the only team member with rather controversial political views. As long as these views don't meaningfully impact her work on Rust, why shouldn't she be on the team? Why can't we just learn to be more tolerant of dissenting views?
The link goes into detail about her effect on wasm-pack, the official Rust wasm project. Her personal views and behavior at npm aside, this alone should be enough to remove her from being part of Rust in any official capacity. I guess being in a relationship with Steve Klabnik has its benefits.
I didn't said that she should get expelled, however since the moderation team cannot do their job to enforce the CoC when such blatant violations goes unpunished it makes sense for them to disband the moderation team. Why have a moderation team if it is just for show?
We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
And the first line from the Moderation section of that same document:
Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed.
It's not just that it's a controversial political view -- it's a clear violation of the first rule of participating in the community. It's rules for thee but not for me.
If you're a man, I don't see how it would be possible to feel safe or welcome in _any_ association with the Rust community when a prominent Core team member is advocating for you to be killed.
It's like saying that Hitler's position on Jews is just a controversial political view.
The second link in this thread (https://news.ycombinator.com/item?id=28515306) includes multiple alleged statements that are about identity politics. One example being: "saying incredibly horrible sexist and racist things such as 'kill all men', and actively trying to prevent white men from speaking at tech conferences" Which seems to be connected to identity politics.
I encourage everyone to read the actual links in that post. I'm in no way associated with any party, but the links that supposedly give evidence for specific statements are not as clear cut as it's made out to be.
E.g. with respect to the wasm-pack both sides have reasonable arguments in the thread how I read it.
With respect to unsubstantiated accusation, that very post makes accusations of nepotism without any proof.
This seems to be a case of one person who's said some things that pretty much everyone would regard as inappropriate and potentially offensive (probably regardless of where they stand on CoCs or their views regarding identity politics). I see no evidence of a connection between this person and the resignation of the Rust Moderation Team.
I'd also add that making white men feel unwelcome in an open source software project is very hard work. I am a white man, and would not for a moment feel uncomfortable about trying to contribute to node or Rust because of the indelicate mode of expression of this one individual.
If the core team took her side even though she said those inappropriate and offensive things then it makes sense that the Rust Moderation team felt that they couldn't do their job and resigned because of it. Note that she is a part of the core team.
As you can see this sub thread is just speculation from the first post. The evidence are the links provided in the posts above and the rest is speculation how that could potentially related to what happened today.
That confused me at first, so just to elaborate for anyone else - the moderation team is stepping down, having grievances including an unaccountable core team. Steve Klabnik is on the latter, not the former, so not resigning.
So unless GP is suggesting that the moderation team felt SK's post airing grievances with Amazon was against CoC/whatever standards they expected of him, not related.
I can imagine friction over this piece causing conflict between members of the core team. It could also be that Amazon tried to respond to SK's piece in ways that were against the CoC.
I don't think it does; it's just one of the recent bits of drama within the Rust Team that has leaked out to the public, so people naturally wonder if they are connected somehow. At this point in time, everything in here is just idle speculation at best.
These organizational breakdowns in tech communities (recently Rust,.NET, Elm) make me much more appreciative of long-running, relatively healthy communities.
Technical communities are formed around common purpose. They are not goals in themselves. Community needs only to be healthy enough to get things done.
Take for example OpenBSD. Theo de Raadt may be an asshole sometimes, but he knows stuff can still steer the technology. OpenBSD is extremely opinionated even technologically, but it's really good.
This doesn't scale though, and OpenBSD - as much as I love it - is a clear example of that. Compare Theo who remains abrasive at times, and Linus, who realized that project the size of Linux cannot be handled with complete disregard for safe, inviting environment. Toxic leaders are the reason there's this idea that projects that are built on merit somehow must be ruthless and uninviting. It's really easy to e.g. confuse critique and criticism and in result give project the "avoid whenever possible" badge.
Please don't confuse the breakdowns in specific political groups with overall community. In any realm there are 10-100s of quiet participants for each loud person who takes on some public role and tries to organize things. Enthusiastic bureaucrats often clash unless there's de-fact dictatorship that suppresses such conflicts before they create too much noise. But their problems are not representative of everyone else's work and participation.
There's been a longstanding issue that a lot of people are unhappy with the level of control that Evan exercises over the development of the language. On top of that, a lot of the development of the core language happens behind closed doors, which has given the impression of stagnation over the past few years.
As I understand it, the fundamental reason for this situation is technical. It is really difficult to enforce purity in a strict language with an FFI, because the behavior of side-effecting functions would be predictable and they'd be easy to use. In contrast, while someone certainly could release a Haskell library that made pervasive use of side-effecting functions, the resulting library would be horribly brittle and no-one would want to use it.
Evan really wants Elm to be pure. To ensure it stays that way, he's banned community packages from using the Javascript FFI. This has been unpopular, but I think he's probably right that this is the only way of keeping the language pure.
It comes back to the usual open source entitlement debate. A lot of people seem to really deeply believe that Evan owes them something, and is required to manage his project along the lines of some kind of standard 'open source' model. He doesn't see it that way.
> As I understand it, the fundamental reason for this situation is technical. It is really difficult to enforce purity in a strict language with an FFI, because the behavior of side-effecting functions would be predictable and they'd be easy to use.
My understanding is that
1. FFIs are still available to NoRedInk, Evan's employer.
2. The change was partly justified as a way to manage the Elm ecosystem.
In general, Evan seems to have a history of changing the language in response to changes in the ecosystem that he does not like e.g. he did not like to kinds of custom infix operators people were defining so he removed the ability to define custom infix operators.
> A lot of people seem to really deeply believe that Evan owes them something, and is required to manage his project along the lines of some kind of standard 'open source' model.
I think this is slightly uncharitable. While I haven't followed his activities recently, Evan spent time trying to build community around Elm. People contributed to the ecosystem based on a combination of implicit and explicit promises that the community's needs would matter, I've chatted with a few people who say Evan gave them personal assurances about long term usability. Evan benefitted from some of these contributions, in prestige, bug reports, etc. Then Evan broke almost everyone's code and was unapologetic about it. I don't think it's unreasonable to feel like some kind of social contract was broken.
I think the revealing term here is 'implicit promise'. A lot of people seem to have very fixed expectations about how open source projects should be run, and feel that they've been betrayed if a project isn't run in that way. I don't think Evan is to blame for that, though.
The bottom line is that no project that's run by one person in their free time is able to give assurances of anything over the long term. I do think that if half of Evan's critics had the experience of running a reasonably popular open source project, they'd realize how meaningless any long-term 'assurance' is.
I'm not sure what you're referring to when you say that Evan broke everyone's code. I was writing Elm code as part of my day job during the 0.18-0.19 transition, and it was not particularly painful.
But this is all by the by. The fundamental question is the following. How would you propose to keep Elm pure while still allowing community libraries to access the FFI?
The compiler literally checks what GitHub org originated the package. If you fork a package that uses FFI, it won't work unless you remove the check from the compiler or use a hacky workaround to trick the compiler: https://github.com/elm/compiler/blob/770071accf791e817144070...
Evan also wants to prevent people from making packages that solve certain types of problems so that he'll be able to make a better package in the future without needing to worry people might not want to switch because of backwards compatibility. I think that's entirely his right, but I'm skeptical it'll work.
Clojure and Common Lisp managed to have super stable community-built libraries. I'm not entirely sure what contributed to this (ie did this happen because of a stable core? Did this happen because lisps are somehow naturally conducive to stable extension?) but it's possible to have this happen without preventing community built-libraries.. :<
My impression is that Evan thinks a stable community built library that he doesn't like the feel of would ruin his language, so he'd rather have an unstable library he controls (because he doesn't have the bandwidth for everything). If this eventually leads to lots of stable great libraries written by Evan that would be nice, but until then it doesn't seem worth investing in. Here's what the author of a parsing library had to say
> Of all the changes in 0.19, this is the one that most hurt my code: I have parser combinator library, and used just two custom operators, for the very reasons that Evan points out in at the top.
> Now I learn that elm/parser can, and does, define two operators for parsing, for the same reasons my library had done so. There are indeed times when custom embedded languages with custom operators are worth the mental effort on the programming staff. Parsing is one of them, which Evan acknowledges, and indeed uses in elm/parser.
> However, it is not realistic to assume that elm/parser will become the only parsing package we ever need. For one, it only works on String. Parsing over byte arrays is quite common, (and what mine did). Even if elm/parse had been parameterized on the stream type - there are still differing implementation and functionality tradeoffs in parsers (backtracking, error tracking, error recovery, etc..) that make different parser libraries useful even they support the same stream type.
Maybe I'm wrong, but it seems to me like any time there's a controversy surrounding code of conducts (and just bad behavior in general) with open source projects, it's always on Github. Conversations on Gitlab by comparison always feel a lot more serious and professional.
That could just be due to numbers, since Github has way more people. The low barrier of entry to Github probably also contributes, since it attracts younger/less mature people. The social media features might also cause people to treat it like reddit or twitter, where being an asshole for no reason is normal behavior.
> Conversations on Gitlab by comparison always feel a lot more serious and professional.
I doubt it, at least in my experience this has little to do with GitLab or GitHub.
> The low barrier of entry to Github
In this case no low barrier of entry is involved. There is no low barrier of entry to join the core Team. This is not drama because of a random person posting some random bs on GitHub.
There's an article on The Register about it [1], which includes a helpful link to the archived threads [2].
A quote from the article:
> "I have, on two occasions now, recommended this program to photography and graphic design educators (as an alternative to Photoshop) who told me that they considered it and found it good as software but weren't permitted by their institution to use it in the classroom because of the name."
> Maybe I'm wrong, but it seems to me like any time there's a controversy surrounding code of conducts (and just bad behavior in general) with open source projects, it's always on Github. Conversations on Gitlab by comparison always feel a lot more serious and professional.
That sounds like classic selection bias to me.
There are more projects on GitHub than GitLab so if the probability of any one project generating drama is the same between projects, one would expect more drama to come out of GitHub.
Politics are part of human behaviour. To some extend we need to accept politics.
However, I'm concerned that recently quite some politics seem to be going on with the Rust core team. First the nebolous "I refuse to let Amazon define Rust" tweet. And now this resignment accompanied by another nebolous statement .
Rust is still very fragile and only very scarcly used in business contexts. I'm using it for APIs, love it and want it to succeed. Politics and drama does not support its adoption.
No reasons or substance given. This is how bad orgs continue to operate. Everyone is afraid of pointing fingers at the aggressor. Name and shame. Then If the rust org refuses to fix it, we know who to not involve in the fork.
- A too small (maybe not diverse enough) moderation not being able to upkeep their own standards even ignoring the issues of the core Team.
Both are structural issues. There might have been person-specific issues too, but in the grater picture they don't matter and would just diverge the attention form the structural issues which need to be solved.
Further information might be gleaned from the associated Reddit thread, where one of the mod team who resigned in this post has offered to answer questions surrounding the departure, although not relating to any specific incidents: https://old.reddit.com/r/rust/comments/qzme1z/moderation_tea...
I can understand the moderation team not going object-level in the name of professionalism, especially given that [whoever this really means something to] probably already know exactly what's up. That doesn't make it any less strange or jarring to someone on the outside looking in. Can anyone provide context?
> Are there examples of behavior which went unaccounted?
They don't want to make the specific issues public, but take a stand against the core team being non-responsive to issues raised by the moderation team. We don't know what or why beyond the fact the moderation team feels it can't perform its job when the core team does not submit to the same rules the rest of the community does.
Heh. I couldn't help it, even if it doesn't make much sense. Still, I wouldn't trust them on teams where the goal is transparency and fairness, that's for sure.
People in open source don't seem to understand that major open source communities such as those for Rust are work environments, and in work environments you should act professionally. Don't discuss religion or politics. Don't insult. Respect those who you disagree with.
Not that this specifically will cause any consequence for the language, but it's terrible how entirely possible some similar drama can affect it. This is a complex, unspecified language with a single decent implementation.
I'm glad that they're trying to make their voices heard, but I hope this doesn't have any long lasting effects on the Rust community/ecosystem as a whole. We all (mostly) want to see Rust succeed, but we're struggling on our way there.
There are a lot of companies on the edge about investing into Rust in my opinion, there are a lot of reasons for, but it also generally just feels so unstable and easy to rock.
Being at the centre of controversies, such as the one with actix-web, gives it a bad reputation even outside Rust circles.
I'm not very familiar with these Rust institutions. What are the moderation team and core teams? What places are the moderation team tasked with moderating, and what powers do they have?
I'm fine with this. Let the people work. Moderators rage quitting because they don't have ultimate power over everyone in the organization is probably indicative of an organization better off without them. If the problem was actually egregious, the people in charge of the core team would have allowed the enforcement. A resignation strongly implies that no one in power was on their side.
Some months ago somebody else was complaining about the fact that most of the rust core team was being hired by big corps (mostly Amazon iirc).
In my opinion these people resigning will have the effect of just making core team's life (read: Amazon's and other big corps' life) easier in doing whatever they want.
This response merely preserves the status quo, which is the thing that Andrew and team have an issue with in the first place. This is not an appropriate circumstance where discretion better serves anyone except for the people who were apparently above moderation.
What do you think a moderation team ought to do in a situation where code-of-conduct violations are happening and they can't do anything about it? To stay and not say anything publicly would leave outsiders with the impression that everything is fine and that whatever is happening has their personal stamp of approval. There may be valid reasons they don't feel at liberty to name the parties and say what's going on.
To leave an organization might be their only recourse. Sometimes doing the right thing is necessary even when the outside public is unable to independently confirm that one is doing the right thing.
We have no idea whether the mod team resigning was the best choice, but I'm willing to entertain the possibility that it was. And if they are resigning due to a real problem, then that problem is much more likely to be addressed and resolved by the new moderation team now that the community knows that an issue exists.
Can someone explain why the development of a computer programming language needs "mod teams" and other stuff?
I don't use Rust; does Rust aspire to also be a social network or something?
It seems to me, from my outsider's perspective, that Rust has a lot of bureaucracy for bureaucracy's sake. The "teams" directory [0] has two pages worth of files, which I assume are sub-team membership lists? Good grief.
> Can someone explain why the development of a computer programming language needs "mod teams" and other stuff?
>I don't use Rust; does Rust aspire to also be a social network or something?
Because this development is done by people. Those people need to communicate and coordinate in an effective way, including with people outside of the immediate development effort (i.e. not just writing code).
C++ and Fortran are in active development, but to the best of my knowledge have neither "mod teams" nor the heightened level of drama that Rust seems to attract.
> C++ and Fortran are in active development, but to the best of my knowledge have neither "mod teams" nor the heightened level of drama that Rust seems to attract.
I don't know exactly how Fortran is developed, but C++ developed at the ISO which has its own flavour of bureaucracy.
And correct me if I'm wrong, but I also don't think that C++ has its own - sanctioned - community fora like Rust does.
I hate all the drama that gets spread around the internet with zero or limited context. Everyone gets mad and the extrapolation and speculation on what's going on starts to spread as fact.
After reading through all this, I have no idea what the real underlying issue is. Someone seems to be angry with someone over some incident, but we don't know what the incident was.
What a silly statement. Rust is, for many reasons, what you should be writing your future projects in. It has many forward-thinking features that represent where the field of SWE is heading.
Letting political disagreements dictate what tech you choose is absolutely the silliest thing you can do (except Oracle, which can affect your bottom line). Use the best tool for the job and ignore the noise.
So take the good parts of Rust and put them into some other language.
Some C++ committee members have expressed interest in figuring out how the borrow checker can fit in. Right now nobody as a good idea, but if you do please write a paper.
There are lots of languages to choose from. Each has pros and cons. My company has seen bad results with rust - this is a reflection on the type of programmers who got on the rust project and not rust itself.
IMO it makes sense that the Rust moderation team should also be the Rust core team, and that losing the confidence of your peers is the scope and magnitude of wrong that should trigger action. This will allow some modicum of abuse per the culture of any core team, but it will also align power with incentive and avoid power paradoxes like "who watches the watchmen".
This is similar to how some legislative / deliberative bodies administer themselves.
Sounds like the core team wants to get shit done, and the kind of people in the Rust community who open bugs on the philosophers in the dining philosophers example not being gender- and ethnically diverse enough are assmad about it.
As someone who's used Rust but isn't fully familiar with the community, what would the expected roles of these moderators have been? Is it just forum moderation or are there other components?
The "description" field says "Helping uphold the code of conduct and community standards" which is why they left. My guess is people could of done literally any number of things that violated the Code of Conduct. They want to not start a witch hunt which is respectable. As someone else around this thread said though, it leaves room to interpret it as the absolute worst. I am going to assume it's not as awful as it seems and might just be something to the tune of differing opinions. Maybe another Linus Torvalds scenario, I rather not make assumptions that are really bad.
Good. The Core Team can govern and mod themselves. This general mealy-mouthed complaint about "un-accountability" - with utterly no specifics given - can be crushed and dumped into the dustbin.
If you don't want to "publicize" it, then don't make a formal, public post on Reddit Rust - handle it internally.
If you want to publicize it, then have the courage to provide the specifics to the public.
I don't believe proper free software projects require significant moderation of behavior between individuals.
If someone says something that rises to the level of a crime, report it to your local authorities.
Otherwise, if a person is generally toxic enough, they will be worked around.
Note that expelling a person from a project for being a jerk in one or more instances may do more harm than good. What is the value of their technical contributions? Just how much of a jerk were they?
Unfortunately, some snowflakes like to believe that everyone contributes equally. That is simply not the case. And, in fact, some people contribute a _negative_ amount overall. Which is to say, the project is better off without their participation.
Linux has changed the world -- in a very substantial way and much for the better -- even though Linus flew off the handle at people for years. That doesn't mean he is completely beyond criticism, but it does indicate to me that we need to put a significant check in place against these "feelings committees." Their sensibilities are becoming ever more delicate.
You can't have a complex technical project that is successful without some minimum level of competency. For better or worse, competency often makes people a little rougher around the edges.
Choose your tradeoff carefully.
edit: Adding an addendum here because of a lot of people seem quite triggered by the use of the word toxic and frankly, I don't have time to reply to all of you.
I used the word toxic in this post precisely once, to say that people who are toxic enough will be worked around.
Toxicity is not a yes/no question. It's a matter of degree and context. So is technical contribution.
Everyone is capable of saying things they will regret later. Some people are capable of saying things that everyone else will regret, frequently.
With regards to "competency" and "rough around the edges" -- note I used the phrase "rough around the edges" and NOT toxic. Many of you seem to be making that substitution.
Have the lot of you never worked with someone who knows their shit, is opinionated, and isn't afraid to let you know it? They're often intimidating, even if they don't mean to be. Submitting a PR for review to them can be nervewracking even if they are entirely nice about it. Sometimes a fair critique will cut a little deeper because the code is your baby, and they didn't sugarcoat it enough for your liking. And, once in a while, they're willing to get in a heated debate because they feel strongly about something.
The very nature of being critical (which is required for quality code) is enough to provoke some unwanted emotions in other people. Even if those negative emotions aren't intended. And sometimes, getting into a heated argument about something is justified if it saves a lot of pain later.
Somehow, there is a lot of triggering going on here, and not a lot of acknowledgement of nuance.
> Otherwise, if a person is generally toxic enough, they will be worked around.
This often puts a considerable drag on the whole project, one that can easily climb to way above the contributions of that person. Even worse, this is often not visible at the project level, as multiple people start independently avoiding this person, even finding technical work-arounds to avoid working with them; while their direct contributions are visible to everyone, making it seem like they are indispensable.
The situation with Linus is even more interesting: for years people have worked with him knowing that they sometimes have to endure his abrasive manners. Then, one day, enough people seem to have discussed this with him, and he decided to accept their feedback and change his ways. How much more successful could Linux have been had this discussion happened 10 years earlier? How many developers have quit or never started working on Linus out of social anxiety? Perhaps it's 0, perhaps it's not.
Do you mind sending me in the right direction for more info?
I was around for the infancy of Linux (I remember a friend was running ~2.1.98 because it came out before Win 98 or something like that, even though it was occasionally unstable for them), and then went in another direction, and have recently gotten back in.
Sage (previously Sarah) Sharp is the most public one for the Linux project specifically. You could probably find more by starting your search there (and enjoy wading through all the invective aimed their way 'cause oh boy was there a lot).
> You can't have a complex technical project that is successful without some minimum level of competency. For better or worse, competency often makes people a little rougher around the edges.
This is just nonsense. Plenty of intelligent and capable people are perfectly friendly and non-toxic.
Your philosophy demonstrably doesn't work. Its failures are so obvious that even Linus Torvalds, who people always seem to bring up in these conversations, has repudiated it[0].
> And, in fact, some people contribute a _negative_ amount overall. Which is to say, the project is better off without their participation.
This is true. Toxic people aren't worth the effort to keep them in, no matter how good their skilled contributions are. There can and should be a way to remove them.
"Toxic people aren't worth the effort to keep them in, no matter how good their skilled contributions are. There can and should be a way to remove them."
This is your utopian ideal - it is NOT indicative of the real world. Sometimes, there are horribly toxic people who are so competent and requisite to a project that their removal would cause immediate and irrecoverable failure.
You made your statement as matter of fact - it is absolutely wrong. There may be times, perhaps even a majority of times that you can simply remove a toxic person - but to state it as the hard rule without exceptions is wrong.
I'd call my statement an opinion, not a fact, but we can add an "In general," in front of what I said and note that there'll be exceptions from certain standpoints.
I think those exceptions are very limited, though. There seems to be an implicit judgment here that the success of the project is usually more valuable than the well-being of the people who are helping to complete it, and in the vast majority cases of I disagree. Unless literal life and death are on the line, it's hard for me to see it as worth it.
As an individual, my rule is pretty hard and fast and that's why I phrased it so definitively. I don't really care how much money is being offered to me or how cool or important the project is, and I don't really care how critical the person is to the project. If the choice is "allow the toxic person to be toxic or allow the project to fail," I'll vote with my feet and I'll leave.
Given the context, I suspect the parent was referring to the overhead caused by managing incompetents. Given the choice between working with an asshat who knows what they're doing and a moron who doesn't understand the basics _and can't be taught_, which would you take?
I assume in the open source world the latter is easier to ignore, but in business it can take years to get rid of an incompetent, and the longer they're there, the greater the drag on the team and the harder it is to hang on to talented people. By contrast, letting a talented and productive asshat go is much easier; just introduce them to HR!
> Linux has changed the world -- in a very substantial way and much for the better -- even though Linus flew off the handle at people for years. That doesn't mean he is completely beyond criticism, but it does indicate to me that we need to put a significant check in place against these "feelings committees." Their sensibilities are becoming ever more delicate.
I think that's a pretty bad example, considering Linus took time off and reevaluated, publicly apologized and acknowledged how his behavior was harming Linux.
> competency often makes people a little rougher around the edges.
There's a difference between how very bold Linus was with his insults to today's "cocs" which makes people walk on eggshells being too afraid to say or insinuate something that may be perceived as "incorrect".
They say if you feel like you're walking on eggshells, it means you're in an abusive relationship.
In the olden days of forums we had none of this nonsense. The community would agree a user was toxic and the mods would kick. It seemed like there were better controls, or that this was a better design.
Maybe because GitHub is so centralized, and every action so public it feels like there is some kind of global audience, so there are all these wasteful airs and graces? Idk
Acording to the link I have to be friendly, safety inducing, welcoming, kind (non rude), keep unstructured critique to a minimum, non-insulting and be careful not to demean or harass anyone.
This is ripe for misinterpretation and witch-hunting. It will get people to walk on eggshells.
In my circles these rules are called comon sense. We don't have to write things down because every adult knows the rule: Don't be an asshole.
Most of this is the accepted behavior for white people in San Francisco (somewhere on the scale from nice to passive aggressive), but not so much outside the West Coast. Although, many British insults read as compliments to Americans, so maybe it's possible to maliciously comply.
> Please be kind and courteous. There’s no need to be mean or rude.
> Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could’ve communicated better — remember that it’s your responsibility to make your fellow Rustaceans comfortable.
Us Norwegians are well known for coming across as rude. And especially since being mean or rude is a subjective thing, I feel it's highly likely I could come across as unintentionally rude to others. And according to that it's my fault if I do.
I definitely think twice before interacting with a community that has a CoC like that, because I don't need such drama in my life.
The Rust community is famous for being friendly. This means that people who are not good at being friendly are being careful what they say there, or have left that space.
> Linux has changed the world -- in a very substantial way and much for the better -- even though Linus flew off the handle at people for years. That doesn't mean he is completely beyond criticism, but it does indicate to me that we need to put a significant check in place against these "feelings committees." Their sensibilities are becoming ever more delicate.
Even Linux admits his behaviour was unproductive and has apologised and improved his communication.
Personally, I think an expectation of a little professionalism from people is hardly "ever more delicate". Rather, it's people who feel entitled to spout any profanity or insult they want without reaction who seem unable to deal with the consequences of their actions.
> Otherwise, if a person is generally toxic enough, they will be worked around.
What you are describing is that if you are "valuable enough", you get to be toxic to people without consequence. That's a good way to breed toxicity.
There is this trope of the "genius asshole" who is too valuable to lose. I suspect that in a lot of cases these people are too valuable precisely because they drive away other contributors that would otherwise lead to a more healthy project.
> Unfortunately, some snowflakes like to believe that everyone contributes equally. That is simply not the case. And, in fact, some people contribute a _negative_ amount overall. Which is to say, the project is better off without their participation.
You intended this to support your argument, but it seems to undermine it. The odds are that one individual is going to contribute less than all the people they are likely to drive away with toxicity. Toxic developers are likely to be the net negative contributors as you describe.
It really seems like your whole argument is predicated on capability and toxicity being directly correlated, which in my experience—while something toxic people want to believe—is a nonsense excuse for enabling bad behaviour.
> There is this trope of the "genius asshole" who is too valuable to lose. I suspect that in a lot of cases these people are too valuable precisely because they drive away other contributors that would otherwise lead to a more healthy project.
I have seen this many a time.
It's quite hard to watch someone tear themselves apart, even if it is just the internet. The emotional burden of it gets a bit too much, and walking away seems like the best option.
I work at a volunteer and we had someone with some skills come in but they were pretty toxic. We had a some of volunteers leave or contribute less. We've sometimes had disagreements on this project before (a website.. not super technical), but this was a new level of bad.
Skilled people have lots of options for volunteering and they'll just leave and volunteer somewhere else.
> Note that expelling a person from a project for being a jerk in one or more instances may do more harm than good. What is the value of their technical contributions? Just how much of a jerk were they?
The way we used to deal with this was by divorcing communication from contribution. Someone might be banned from a mailing list or IRC channel but their contributions could still be merged (and they might even have write access to the main repo, in extremely rare cases).
I think it's still the case that a lot of the "pro vs con" debates around mod teams could be addressed by divorcing the social aspects of development from willingness to consider PRs. And I've never seen a cogent justification for not making this split.
> For better or worse, competency often makes people a little rougher around the edges.
I don't buy the causal link at all. I think it's more likely that competency in software often used to let OSS contributors get away with being assholes because there was so little free-as-in-beer competent labor available. Programmers, even ones who will work for free, aren't such hot shit anymore.
> snowflakes
I think we've gotten to the point where we can s/snowflakes/meany-face/. It's juvenile name calling that distracts from your point and makes people take you less seriously.
> Otherwise, if a person is generally toxic enough, they will be worked around.
No. If a person is toxic enough, people will leave until that person has total power or that person is removed.
This is what I have seen happen at companies over and over again.
It can be a painful process because that person may not be actively mean or bad. The way I have seen it happen most often is that the person talks endlessly, and are control freaks that do not allow anyone else to make decisions about any project they are involved in. They don't mind arguing for hours, so the team quits trying to communicate with them over time and ends up leaving.
Also, you act as if toxic == productive, which is absolutely not the case. Smart people tend to be T shaped, which means they also have good social skills. The myth of the "toxic genius" is just that: a myth. Most of the best developers I have met are extremely nice people.
> Otherwise, if a person is generally toxic enough, they will be worked around.
While this is generally true the workarounds can and do take time, and while all this is happening there's a lot of space for a person to do significant damage to the project in the meantime.
That's a feature, not a bug. Most big decisions can and should take time. Usually because it's not a simple matter of "this guy is a massive dick to everyone and contributes hardly anything."
More often it's "this guy carries this project, and he is an asshole when people show up and run their mouth because they think they're smarter than they are." Which is to say - it's a shade of gray, not black or white.
In the truly dire situations, movements happen quickly. See the recent collapse of FreeNode IRC.
Is it coincidence that it is so common toxic people end up being the ones "carrying the project", or is it that because they are toxic, they push away other contributors and create a fragile project with a bus factor of one?
Seems to me getting rid of those people sooner rather than later is better for the health of the project overall.
Of course, I'm sure some will argue that it's no coincidence because being effective and being toxic are inherently positively linked, but that's simply untrue in my experience, wishful thinking on the part of toxic people who want an excuse for their behaviour. Linus himself has said he was wrong to act as he did, and has worked to change that, and seen improvements for doing so.
> Usually because it's not a simple matter of "this guy is a massive dick to everyone and contributes hardly anything."
No, but if someone is a massive dick to everyone, the quality and quantity of their contributions shouldn't matter. Being a dick is being a dick. Doesn't matter what they contribute.
And how many incredibly-productive people have been chased off of products by the toxic individuals that were being "worked around?" We may never know. You act as if we can have perfect knowledge into what the tradeoffs will be, but that just isn't the case.
Also, I don't think there are very many people who match your strawman -- "snowflakes [who] like to believe that everyone contributes equally." If you've worked in software (or really in any industry) for any time at all, you know that everyone is an individual performer with their own individual pace. But if you believe that that pace is solely a factor of their own productivity and isn't influenced by the environment they're in, you're being incredibly naive. Those toxic individuals are usually the ones that contribute the "negative amount overall" you mention, due to how they poison the atmosphere and reduce everyone else's output.
Which is to say, the project is indeed better off without their participation.
Back in the day, Linux (and other FOSS projects) where for geeks only. You invested your free time on it because you liked it. People could be aggressive against you, you would leave and nobody gave a shit.
Modern FOSS projects such as Linux or Rust are more than something for geeks. Lot of people gets paid to work on it. For many, being an expert in an important project is a career, not just a job. People are "forced" to spend a lot of time working with the community. And modern open source projects just have far more people than they used to. I guess that the standards have been raised.
That said, I think you are completely right on this point:
> some snowflakes like to believe that everyone contributes equally
This is absolutely right. The people who are being accused of being nasty are the _core_ team. Rust just can not exist without them. Unfortunately, they seem to be abusing their power.
I think you're missing the point. Whether or not everyone contributes equally is irrelevant (and I agree with you that all contributions are far from equal). But no one deserves to be treated with disrespect, and no one deserves a pass for treating others poorly just because their technical contributions are rated so highly.
If a project can't survive without its toxic people, then perhaps it shouldn't survive.
> Otherwise, if a person is generally toxic enough, they will be worked around.
Echoing simiones,
'worked around' here means that other productive members of the community will become disillusioned and leave.
The toxic person will become a 'known problem' that is talked about in hushed tones.
People will devise small scale strategies for avoiding the bad behaviour.
> Note that expelling a person from a project for being a jerk in one or more instances may do more harm than good. What is the value of their technical contributions? Just how much of a jerk were they?
We had a publicly 'productive' architect for many years that loved to talk about his technical contributions to the President and CTO, but the actual effect of his contributions was negative.
He refused to coordinate with other teams, and everyone who had to interface with his work were forced to rework APIs according to his current whims.
He belittled people publicly when they weren't present, and I watched him steal credit for other's achievements. He would then complain that no one appreciated what a hard worker he was to anyone who would listen.
On top of all of this, his actual architectural decisions were unsound, as they centralized his work, that only he could maintain, as a core component of the system. In 10 years, he only had one direct report that could tolerate him enough to help with his codebase.
> For better or worse, competency often makes people a little rougher around the edges.
An unsupported assertion.
I've personally found that toxic people are much more willing to aggrandize and lie about their competency to people who don't know better.
The best programmers I've worked with were all cooperative and positive 95+% of the time, focused on the product and not their ego.
> we need to put a significant check in place against these "feelings committees." Their sensibilities are becoming ever more delicate.
I think this is the bigger problem.
There is a real danger of the line between "socially acceptable" and "strongly disagree" or "strongly dislike" being blurred by these groups... it needs to be ok to have people disagree with each other, or not like each other, or not like their opinion, or not like their personality in these open source projects without that leading to being ejected or punished for it.
I'm reminded of this mid-2000s example of toxic behavior from Richard Stallman on Emacs, in response to a contributor who didn't have time to work on something because he just had a baby girl: https://tess.oconnor.cx/2005/04/rms
> It doesn’t take special talents to reproduce—even plants can do it. On the other hand, contributing to a program like Emacs takes real skill. That is really something to be proud of.
The obvious point is that he was being funny at that contributor's expense, which is asshole behavior. He's also showing his complete lack of appreciation for the guy's past contributions to the project. Just terribly rude all around.
> if a person is generally toxic enough, they will be worked around
Yes, they will. For 25 or so years, the workaround has been others leaving and the project/site dies. There's nothing original about your argument, and it's been proven to be a destructive strategy. (Ironically, you are posting your comment on HN, which is heavily moderated.)
The classic "free market will decide if being an asshole is worth it to them". This notion is ironic seeing how an entire moderation team resigned. Sounds like they decided it wasn't worth it.
Outing toxic contributors so they don't actively corrupt and corrode the project is tantamount to the long-term success of a project. And you don't need to break the law to be deemed too negative to be necessary.
> Otherwise, if a person is generally toxic enough, they will be worked around.
This comes at a large cost of a lack of any kind of formal consensus process or coordination. It is very hard to run a large ship when it's not organized, and that decision often ends up reflected in how projects evolve.
Compare and contrast programs like Krita/Blender that have formal processes that keep them aligned with artist interests with either free-for-all or "benevolent dictator" Open Source projects that much have less direction. You give something up when you decide that your design/contribution process is going to be totally anarchistic; you lose the ability to keep a program/project focused on a singular goal and to plan for the future.
> Linux has changed the world -- in a very substantial way and much for the better -- even though Linus flew off the handle at people for years.
Note that Linus being toxic doesn't mean he wasn't heavily moderating Linux. Linus's personality problems weren't a problem of lack of moderation, they were a problem of how Linus moderated and what he moderated. In many ways, Linus's toxic behavior was a form of moderation/gatekeeping: it demanded a certain style of contribution and interaction when you entered into the mailing lists. Far from being a free-for-all, Linus demanded (and still does, although he's trying to be better about the way he demands it) a lot of focus on code quality, standards, and communication style when submitting and describing contributions.
> For better or worse, competency often makes people a little rougher around the edges.
I think we would save some time if we recognized that opposition to moderation policies often comes down to disagreements about specific social debates (is it OK to be a jerk if you're good at your job, are certain words OK to use, what communication styles should people use), rather than philosophical disagreements about the nature of moderation in general.
It's also worth noting that the assumption here that the mod team's complaint is about people being rough around the edges is just an assumption. The mod team has not given a public complaint other than that there were incidents that they felt were mishandled, and that they felt they were out of alignment with the core team on moderation direction. We don't know what happened.
Does anybody actually care about the moderation team anyway? CoC is also just set of guidelines that people abide by anyway in most situations, but doesn't prevent anybody from being an asshole. When somebody is an asshole, random set of people can't really do anything about it.
What exactly was the role of this team? how exactly it came into being?
I suspect that we are starting to see the reaction against the CoC entryists in open source projects.
I'm inclined to believe the rust moderation team even though they haven't disclosed any specifics. The way the core team exercises absolute authority in spite of community complaints has always rubbed me the wrong way. They present a facade of caring while crushing dissent.
I do not recognize most of the core team these days, but Steve Klabnik and Ashley Williams stand out as likely culprits. I have personally submitted an email with the Rust moderation team to complain about Klabnik (and also mod-team member Andrew Gallant) and their abrasive behavior on reddit. Several months later I received a response stating they agreed that Klabnik went over the line and that they would warn him. Meanwhile Ashley "kill all men" Williams has an extremely lengthy reputation for her behavior in open source[1]. When it was announced she was joining the rust community team, there was a large push back from the community but the reddit/discourse mods censored everything[2][3] and the core team chose to let Williams join despite the complaints about her history of racism, sexism, and antagonism.
For what it's worth, Andrew Gallant ("BurntSushi", the author of that post) is probably the voice I most trust on the Internet today. For a long time now, he has demonstrated that he is extremely judicious, level-headed, and well-thought-out on any position I've ever seen him take. People are not always polite / nice to him, and he unfailingly responds kindly and honestly with a level of effort that is truly amazing. He consistently demonstrates that he truly cares on a personal level, even when the situation is "unfair" or that level of care isn't being reciprocated.
All that to say: this message came from Andrew, and I believe it without question.
But the mod team who resigned were precisely the ones behind moderating those Reddit/Discourse threads though. So I don't think there was animosity between the two teams from the start, but rather that tensions grew over the years until it became unmanageable.
My interpretation is that the drama happening around the core team (like the things you've mentioned) gets increasingly overwhelming for the mod team to handle, leading to complaints against the core team for causing such drama (which they do not have the sufficient resources nor actual power to handle). This further escalates and devolves into a worse relationship between the two, leading to the resignation.
From the thread on /r/rust one of the mods (different from the Rust's mods) talked about the relationship between the Core and the Mod team:
Bans. We do not directly enforce bans, instead we ask Core to enforce them for us, and Core will double-check our work (though without access to the case, unless complainants are OK with that) -- essentially ensuring that we've done our due diligence, given a fair chance to the person, and that we're following the "escalation" procedure.
Bans (bis). Core may enforce bans by themselves, then let us know.
Involvement. When a Core Team Member is involved in a complaint, or a difficult relationship, we play our mediator/arbitrator role, stepping in and attempting to figure out the bottom of the issue and resolve it peacefully -- much like we do with any other Rust Team Member, really.
This is maybe a workable agreement if the Core and the Mod team went along well, but currently it seems like that's not the case. The last clause (Involvement) basically tells that "we really don't want the two teams to fight, and things should be resolved with common sense". Now that this is way out of the window, perhaps it would be a good time for the Rust contributors to reevaluate their team structure.
> But the mod team who resigned were precisely the ones behind moderating those Reddit/Discourse threads though.
I thought same as well, but seems reddit mods are different:
> Please note that the official Rust moderation team is not the same organization as the team that moderates the subreddit here on /r/rust. The subreddit is an unofficial space, and though it is frequented by many who are affiliated with the project, it remains independent from the Rust project. The /r/rust mod team is not resigning from moderating the subreddit.
> In the interest of disclosure, two of the moderators who are resigning from the official mod team are moderators here on this subreddit (matthieum and llogiq). They appear to have not resigned their position here, which I appreciate, since they're rather excellent moderators. However, in the interest of impartiality I am asking them to recuse themselves from taking moderator action in this thread (they may still comment as usual if they wish, of course).
Yes, as you’ve said, some of the mods in the Mod team were also the subreddit mods, and they deleted the comments and locked the threads by their own volition (even without requirement from the Core team, so this reinforces my interpretation). It’s likely that the Mod team wasn’t adversarial with the Core team from the start, but tensions gradually grew as the drama surrounding the core team got unmanageable.
> Yes, as you’ve said, some of the mods in the Mod team were also the subreddit mods, and they deleted the comments and locked the threads by their own volition (even without requirement from the Core team, so this reinforces my interpretation)
But AFAICS the core team being involved in moderation activities has nothing to do with Reddit. That quote above on how the teams were supposed to cooperate was about moderation of the official Rust forums, wasn't it? Reddit isn't one of those.
So if you're seeing your interpretation confirmed, that's just... Wrong. It doesn't confirm anything of the kind.
None of the links you have provided shed any light because it's all deleted comments. Would you mind elaborating on Ashley Williams and her supposed "racism, sexism and antagonism"?
The problem with this theory is that the moderation team has been entirely supportive of Ms. 'Kill' so far, and actively works to silence dissent about her position in public Rust spaces. (Maybe not so much as the unofficial mods, but I personally was on the receiving end of llogiq's overreaction in /r/rust to any dissent.) I believe they would take her side in the dispute which Klabnik vaguebooked about a few months ago.
This is a real shame. From the early days of Rust (pre-2018?) I built up this mental picture of it having a considerably better run and governed community, with people putting time into thinking about how a community should work rather than it being something that's ignored because "we're here to write code and managing a product is a waste of time".
I lost touch (the last video I watched which might be the one that give me the feels for it was https://www.youtube.com/watch?v=J9OFQm8Qf1I, I do recall Ashley Williams & her ideas were a big part of why the community looked so good from outside; contrasted with the "do-ocracy" one I'm in) so I don't know what happened - but it's sad it's become like other projects now.
Ew. At the beginning I was expecting it to be somewhat interpretive, but some of those statements are indefensible to me, and there's quite a lot.
Some might attempt to explain it away as Twitter's model and ecosystem encouraging ill considered statements, but the adult response to that is to take more care in what you say or stop using the medium that encourages you to say horrible things you regret.
Edit: I will acknowledge the data I was looking at is a few years old, and I don't know if the person in question has since recanted on those views. I believe people change and should be given the chance to leave their past misdeeds behind, and I have no knowledge one way or the other if that happened here, and that would be important to know to have an informed opinion.
Relevantly enough, given this is about moderating the rust technical team, Rod Vagg had this to say about moderating the nodejs technical team:
“My assessment of the claim that I am a hindrance to inclusivity efforts is that it hinges on the singular matter of moderation and control of discourse that occurs amongst the technical team. From the beginning I have strongly maintained that the technical team should retain authority over its own space. That its independence also involves its ability to enforce the rules of social interaction and discussion as it sees fit. This has lead to disagreements with individuals that would rather insert external arbiters into the moderation process; arbiters who have not earned the right to stand in judgement of technical team members, and have not been held to the same standards by which technical team members are judged to earn their place in the project. On this matter I remain staunchly opposed to the dilution of independence of the technical team and will continue to advocate for its ability to make such critical decisions for itself. This is not only a question of moral (earned) authority, but of the risk of subversion of our organisational structures by individuals who are attracted to the project by the possibility of pursuing a personal agenda, regardless of the impact this has on the project itself. I see current moves in this direction, as in this week’s moderation policy proposal at nodejs/TSC#276, as presenting such a risk. I don't expect everyone to agree with me on this, but I have just as much right as everyone else to make my case and not be vilified in my attempts to convince enough of the TSC to prevent such changes.”
> with people putting time into thinking about how a community should work
The sort of people who try to intentionally "plan" (I.e. socially engineer) community dynamics do not have a great historical record of actually creating good communities. History is littered with failed inorganic communities - from cults and communes to web forums with overzealous mods.
Not saying that's necessarily what happened here, just that people putting a lot of thought into how to control/manage a community might be more of a negative sign than a positive one.
> people putting a lot of thought into how to control/manage a community might be more of a negative sign than a positive one.
A counterexample is Hacker News itself. We all like Hacker News (presumably, otherwise we wouldn't be here) and it wouldn't be what it is without the intentions of the original creator and the current moderation team.
That can't be true, right? Everyone shits so hard on HN all the time. Personally I only post here because it's "the place" for people in my field, but HN has given me a more negative view of my field than positive.
Do they? Or is it just some minority of shit stirrers? Or is it that HN is more likely to have people that can healthily laugh at themselves - a la Monty Python? I mean you can love HN and n-gate.com at the same time right?
Back on topic: The very public “we quit” message seems like a very clear message to try and effect change for a cause they deeply care about.
I presume the mod team had multiple other options on how to deal with the core issue. For example, they could have internally suggested a quiet rollover to a new mod team over a few months. Say modelled on how CEO leadership is changed, avoiding public drama, when a CEO is rolled by their board.
Deciding on a very public option just causes all the drama to play out with every Internet and Hackernews (including me) adding their own spit into the mix.
Yeah, they definitely do, or at least virtually everyone I know feels that HN is a place mostly to go to laugh at the terrible opinions or, much less frequently, a good comment.
Both kinds of thinking are natural. Defense mechanisms are always present in the process of making up our minds. But if defense mechanisms are allowed to dominate our thought process-- to kill feelings before they can provoke new thoughts-- the result will be indecisive, ambiguous writing that implicitly dumps the burden of resolving the anxiety, resentments and other dark feelings, onto the author's audience.
An elite who publishes their overthinking signals their inability to resolve their feelings or the feelings of the people they have power over.
I know very little about the Rust community or who Ashley Williams is, but since what you're suggesting sounds pretty serious - perhaps you could be more specific?
> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
There is no substantiations of the claims of bad process by the mod team. There is nothing to be sad about except that the mod team has succeeded in creating noise with no signal.
From the rust subreddit, which apparently is an "unofficial space" does not want people to discuss any specifics either. Why is this discourse happening in public? They want to use public opinion to bring reforms to the Rust governance but not divulge any details?
Does Rust really have a community if noone but a few select member have access to the information regarding why things are changing and the community members can't even discuss the forbidden topics in "unofficial spaces" either. How do I decide if I an getting involved with a community or just an elite club.
Quoting from the stickied comment from r/rust moderator.
> In the interest of not hastily jumping to conclusions, we will be removing speculation that alleges that this is due to any particular individual(s). The moderation team appears to have gone to great lengths to avoid naming names, ostensibly in the service of focusing a spotlight on the core team as a whole rather than any of its members. If they had wanted to name names, they could have. I understand that it is difficult to discuss a topic without firm details, but please refrain from engaging in speculation. I have confirmation that the core team will be making a statement about this at some point, which will hopefully shed more light on the situation.
>Does Rust really have a community if noone but a few select member have access to the information regarding why things are changing and the community members can't even discuss the forbidden topics in "unofficial spaces" either. How do I decide if I an getting involved with a community or just an elite club.
As a first order approximation, the word "community" is so overused as to mean nothing. It's often used to obscure a power structure, or pretend a mass of people are more cohesive than they are. Sometimes both. Don't go into any software project expecting more.
Rust is a big club and you ain't in it. You can still use it, submit patches, maybe even work towards a position in their project hierarchy. The important thing is you got your first strong sniff of knowing where you stand in relation to the club.
Because that's the appropriate scope to discuss what the moderation team wanted to start a discussion about: Processes and structures.
> They want to use public opinion to bring reforms to the Rust governance but not divulge any details?
What they said was basically "Someone did something shitty, we wanted to clean up the discussion, but couldn't because of the current structure where the core team isn't | doesn't see itself as being under any obligation to listen to the moderation team".
Those are all the "details" needed for the subject of the discussion, namely processes and structures. The details of the original "shitty thing" are irrelevant; the same (lack of appropriate) processes and structures applies to any such incident involving the core team.
This all seems pretty self-evident to me; I'm dumbfounded by how many commenters here on HN can't seem to grasp this fundamental but utterly simple difference.
Your quote from the subreddit only shows that the moderators there do get it (no wonder, being partly the same people), and are therefore (quite properly IMO) trying to quell speculation about the (irrelevant!) "original shitty thing".
It shouldn't be so hard to see that there's absolutely nothing wrong with that either.
> You'll never get everyone to settle on the same moral values so it's inevitable that you'll get someone who is unapologetic about some value they hold.
I'm less familiar with Rust community moderation, but as an example of what not to do, I would offer up the Go maintainers' strategy of advertising unrelated, partisan, ideological content on their web pages and then shutting down any kind of critical conversation about it. To be clear (if only so people know what they're downvoting!), I'm an avid Go enthusiast--the language is great and the maintainers are generally good at designing a language; however, I sharply disagree with their approach to managing the community.
I mean they certainly have a partisan stance re: prisons and incarceration. Not to say whether it's a good stance or not, but it's certainly partisan. Partisan doesn't mean "I disagree with this."
But whatever it is and whatever your opinion of it, it's hard to make a cogent argument that it belongs as a banner on the front page of a programming language website.
> I mean they certainly have a partisan stance re: prisons and incarceration.
I did not realize that providing counsel to inmates was a partisan issue.
> But whatever it is and whatever your opinion of it, it's hard to make a cogent argument that it belongs as a banner on the front page of a programming language website.
Unrelated to your comment maybe, but not the thread. It's certainly germane whether your choose to acknowledge it or not.
I'm clearly not referring to "providing counsel" and it takes only 10-15 seconds of reading their homepage to see policy positions that any reasonable person could consider partisan. But nice straw man. Let me know when you're interested in an actual discussion and not this nonsense.
At this point, the slogan "black lives matter" seems to be more of a partisan talking point than any kind of indication that the person using it does, in fact, consider black lives to actually matter. Up to and including shooting white people somehow being more of an attack on the notion that black lives matter than shooting and killing a black teenager, just because of the perceived partisan affiliation of the shooters...
EJI has fought against the death penalty and taken sides on other partisan issues. I wouldn't call it a partisan organization myself, but I can see how someone could reasonably form that opinion.
Generally speaking, organizations providing statements in favor of human rights have been in fairly safe territory. Historically, businesses supporting desegregation, the Civil Rights Act, LGBTQ inclusivity, or other human rights issues have been either unharmed or benefitted from the stance, even if there's no material contribution to the cause, and even if the fight for human rights is partisan (it almost always is.)
No one disputes the human rights of black people. What is disputed is whether police killings are racially motivated or whether American police are too often heavy handed irrespective of race (94% of Americans believe that some police reform is needed[0]).
Of course, virtually everyone understands that blacks are killed disproportionately by police, but that doesn't imply a racial motive when we know for fact that there are disparities in the commission of violent crime, rates of police interaction, etc which could also explain the disparity in shootings.
And of course, the particular remedial policies depend significantly on the answers to these questions. In particular, people who identify strongly with BLM are much more likely to advocate defunding or abolishing the police (but are also the least happy that inadequate policing led citizens to defend themselves during various BLM riots in 2020, including the Rittenhouse case).
Further still, there's a lot of controversy over whether violence or non-violence are the appropriate way to seek the reforms one desires, with virtually the whole of the media downplaying or actively justifying political violence (even invoking MLK's "riots are the language of the oppressed" out of context[1]) right up until January 6th, 2021 when political violence abruptly and rightly regained its "reprehensible" designation.
Further still, contrary to the media portrait, a majority of black Americans don't support violent protest or the abolition or defunding of police--like most other Americans, they want sensible police reform[0].
So yes, BLM is quite controversial in American politics for reasons which have little to do with clear cut advocacy for human rights.
[0]: https://news.gallup.com/poll/315962/americans-say-policing-n...
[1]: One of the more memorable examples was CNN adding the "fiery but mostly peaceful" caption as a journalist sporting a gas mask reported against a backdrop of a dozen burning vehicles.
Black Lives Matter is a slogan used by disparate groups for a variety of causes. The slogan "Black Lives Matter" is necessarily one focused on the human rights of black people.
The Civil Rights Movement of the 1950s and 1960s in the US also involved violent riots by some actors, and there was public debate between sides on whether segregation was intrinsically a cause of inequality, similar to how there is debate today between sides on whether our criminal justice system is intrinsically a cause of racial inequality. If one didn't view segregation as intrinsically unequal, they might claim that the Civil Rights Movement (though focused on many other issues as is BLM) had "little to do with human rights." Supporting the Civil Rights Movement, a movement that contained numerous groups, goals, and actors (both violent and non-violent), was still a position that doesn't seem to have harmed organizations of the day, and may have even benefitted them.
> Black Lives Matter is a slogan used by disparate groups for a variety of causes. The slogan "Black Lives Matter" is necessarily one focused on the human rights of black people.
If we can agree that this slogan is controversial, then it seems like we should be able to agree that the Go project could make its points better by avoiding a controversial slogan and instead using an unambiguous statement. Certainly this should be open for discussion.
Moreover, I could make a similar statement about "All Lives Matter", which is necessarily focused on human rights, but most people steer clear of the slogan because the media has worked to associate it with right-wing groups and now it is only used by right-wing groups--good faith people strive to make their points in ways which are unambiguously good faith; bad faith people use motte and bailey rhetoric which is what the Go team appears to be doing (they are certainly aware of the controversial nature of the slogan and refuse to discuss it).
> The Civil Rights Movement of the 1950s and 1960s in the US also involved violent riots by some actors
Right, and we collectively rebuked those actors and raised up non-violent actors as exemplars for social change.
> there was public debate between sides on whether segregation was intrinsically a cause of inequality, similar to how there is debate today between sides on whether our criminal justice system is intrinsically a cause of racial inequality.
Public debate is fine. Burning and looting neighborhoods, attacking innocent people, etc is not.
> If one didn't view segregation as intrinsically unequal, they might claim that the Civil Rights Movement (though focused on many other issues as is BLM) had "little to do with human rights."
Right, but through public debate and other non-violent means, we made the case that segregation is intrinsically unequal. With respect to BLM, note that there was an enormous effort to punish people for criticizing BLM.
> Supporting the Civil Rights Movement, a movement that contained numerous groups, goals, and actors (both violent and non-violent), was still a position that doesn't seem to have harmed organizations of the day, and may have even benefitted them.
We supported the Civil Rights Movement because it largely emphasized non-violence. We supported the movement in spite of its violent elements, and the violent and nationalist figures remained controversial right up until BLM folks made them popular.
In a political environment where one party openly allies with those that seek a white ethnostate[1] and the other sees a compromise solution that normalizes and rationalizes the existence of its opposition[2], the fair and equal application of the law is not just partisan, it is increasingly countercultural.
Only a small minority of Americans--including ~80% of black Americans--even accept your framing of the problem. In particular, by all appearances, police shootings aren't unequally distributed by race when we account for even the most obvious relevant factors (e.g., violent crime rates), but your whole framing depends on this. In other words, if this isn't true, then the Republicans and a significant minority (if not majority) of Democrats aren't white nationalists but rather opposed to police reforms which can't work* because the problem is misstated.
"Framing" is irrelevant to my statement. I provided concrete evidence of the two mainstream political parties doing exactly what I said they were doing.
How a particular slogan like "defund the police" polls is not relevant to the impact of moving $193 billion annual local dollars of police funding to better structured, community-centered alternatives.
Conflating evidence-based policy goals and research with how people feel about them in the current present moment is classic misdirection.
> I provided concrete evidence of the two mainstream political parties doing exactly what I said they were doing.
Your first article (from Buzzfeed of all places) didn't demonstrate a white nationalist agenda, and if you think the second article supports your point (that Biden is content with whatever white nationalism exists within the Republican party) then I'm not sure we read the same article. The article I read clearly depicts Joe Biden's views that America needs two political parties, that American politics should revert back to the more functional pre-Trump years (and presumably before the alleged mainstreaming of white nationalism that you purport), and that Republicans who want to stay Republicans should do so while voting for Biden. None of that seems controversial at all.
> How a particular slogan like "defund the police" polls is not relevant to the impact of moving $193 billion annual local dollars of police funding to better structured, community-centered alternatives.
You don't think it's a problem that Black Americans overwhelmingly reject policies (as well as rhetoric and ideology) that are purportedly in their interest?
> Conflating evidence-based policy goals and research with how people feel about them in the current present moment is classic misdirection.
"Defund/abolish the police" policy goals aren't evidence based. If you'd like to retreat to the moderate position that we should increase social services while reforming policing, then welcome to the moderate club.
>"Defund/abolish the police" policy goals aren't evidence based.
This is absolutely false. Community groups have been putting together actionable, concrete and evidence-based abolition-centered strategies since the first slave-catchers were paid by the state. Educate yourself.
They'd do well providing some root causes for this blowout. "Core team won't take CoC" is a bit of a cop-out. If the conduct is legal, IMO people who contribute most of the code should have more weight when deciding moderation related issues (and people who contribute none should have no say at all).
Show me the transgressions that would require CoC to be enforced and then I'd be more sympathetic. As presented, this seems like political bullshit, and their efforts would be better spent overhauling Rust's unergonomic error handling.
That is an extremely GamerGate-smelling list. Quotes are misinterpreted, overreacted to, and/or taken out of context.
That list does not contain juicy details; it does contain a level of grime that I figured would mean it would be left in the past as a historical GamerGate artifact and not pulled up in the Rust community in 2021.
Sort of agree, but it does have consequences. It raises questions about long-term governance and decision making in Rust, especially as Rust transitions out of Mozilla ownership into a purely public project.
No, an immature drama would have people slinging feces. This is a highly mature drama where the arguments are dry, generic and adhere to a strict code of values. No fingers were pointed, and the offended party is taking the high road by resigning.
It's not often that people behave in a mature fashion, so I fully understand you did not recognise it for what it is.
What exactly is 'mature' about making a vague accusation, refusing to substantiate it and claiming that if the other side says anything it would be a lie?
The accusation is not vague and it was substantiated. Just not to you. Not to me either, and I think that's a good thing for now. No doubt whoever steps up to become the next mod team will be fully informed by both sides, and hopefully they can make an objective decision about what should and what should not be public. It is probably none of our business anyway.
And it's not a claim that everything they would say would be a lie, it's just a warning. Given the severity of their actions, I'm willing to give them the benefit of the doubt and accept that the warning is probably warranted or at least it feels warranted to them.
"The accusation is not vague and it was substantiated"
The public accusation is vague and is not substantiated. What is the reason for it to exist in the first place if not to put blame without giving a chance to refute it?
> The public accusation is vague and is not substantiated.
You're confused about what the public accusation is. It's not about whatever shitty thing someone on the core team originally did; it's about process and structure. Their complaint was that the moderation team can't moderate the core team, because the latter claims not to be under the purview of the former. Does that really need further "substantiation"? And what's "vague" about it?
And no, the details of the original shitty thing don't matter; the same (lack of?) process and structure would apply to any such incident involving one or more members of the core team.
Justice requires due process. This announcement was made two hours ago. Everyone just wants to instant gratification and to know which party is right or wrong so they can feel good about their minds being made up. We are not the jury here, we're just a tool in their power struggle. They're explicitly not asking us to pass judgement, they're just asking for a new jury.
You're neither the judge not the jury. They aren't trying to make the case to you. The case has (it seems) been made and resolved elsewhere. This is just a public statement saying they do not accept the resolution and therefore resign.
Is it? How would you respond if you were asked to take on a responsibility that you didn't have the authority to uphold? I think this is very sober and professional.
Protecting people's privacy is a fundamental principle of justice, too. It's extremely common for court records in cases regarding people's conduct to be sealed.
Forcing people to air all their dirty laundry in public, as the Puritans did, is not just, and tends to severely limit already-marginalized people's access to justice.
I have been a lawyer for over a decade. In exactly one case that I've ever litigated or supervised has any of the evidence been placed under seal. What jurisdiction do you practice in, that you're seeing this so commonly?
Your argument is flawed since some amount of secrecy/discretion in judicial proceedings is allowed and necessary. For examples look to investigators and DAs who refuse to provide details for ongoing investigations, and closed proceedings.
More importantly this is a problem in a private organization and not a public entity or court proceeding.
> An accusation substantiated in secret is not an accusation substantiated.
This is not about whatever the original "accusation" was; it's about process and structure. AIUI, the whole purpose of having a moderation team is so "dirty laundry" of that kind won't have to be aired in public and ruled on by an uninformed lynch mob. They're talking about not being able -- allowed -- to do their job, not the (irrelevant) details of one specific task of the job.
> This is a fundamental principle of justice, dating back centuries.
And this is a forum moderation team, not a court of law.
>> This is a fundamental principle of justice, dating back centuries.
> And this is a forum moderation team, not a court of law.
Principles of justice apply everywhere. Suggesting they can't be criticized for being unjust, solely because they aren't a court of law... is quite bizarre.
It's "a fundamental principle of justice" when "justice" is read in the sense of "law". Not necessarily otherwise. Principles of law apply in a court of law, not everywhere.
No. There are many systems of law that are unjust. Just like the behavior you are defending. Any accusation "substantiated" in secret is not substantiated at all.
A) The original "accusation" doesn't need to be "substantiated" in public, because that's not what this public part of the debate is about. It's about structures and processes, not whatever the original triggering incident may have been.
B) So no case has ever been decided in closed court in your world, or if any have, they're all unsubstantiated? You need to get your mind out of its over-literal legalistic rut, because in the reality the rest of us live in that happens quite frequently, and much of the time we even trust that allegations made in such courts are substantiated even though they aren't made public.
C) This is still not a "system of law" we're discussing. Try to understand the difference.
Don't make personal attacks. It only underscores the weakness of your argument. I'm not the one being overly legalistic, you are trying to make this a discussion of the legal system.
My position, by contrast, is straightforward: Principles of justice apply everywhere. Full stop.
The fact that this isn't a court of law is utterly immaterial. Allegations "substantiated" in secret are not substantiated at all.
> The accusation is not vague and it was substantiated. Just not to you. Not to me either, and I think that's a good thing for now.
Of course it's a good thing. It's part of the strategy behind this move.
If (when) the accusation turns out to be a relative nothingburger, the Moderation Team would lose the moral authority and hence the power they think they command by going "well fine, we'll take our ball and go home".
Better to let it be vague, so that the public can imagine serious violations that cast the Core Team's legitimacy into doubt.
I can understand why this looks odd if you are not used to how professionals interact over process questions. This strikes me as very similar to how public companies 'fail' audits - which is to say that companies never really fail audits, they just have their auditors resign.
The reason for this is that, when you hire people to validate a process, most of the failure states come from processes that you are unable to verify as good or bad. This doesn't always mean that something is wrong - it just means that the validation team (or the code of conduct team in this case) does not feel, in their opinion, that they can confidently render an opinion. This is important because, at the end of the day, all these teams can do is produce opinions.
The obvious reaction is to suggest changes to the process that would allow you confidence in validation (these are called 'controls' in the auditing world). However, if the group you are trying to validate won't make your changes, then you are left in a situation where you can't be confident about doing your job. You aren't sure that anything is wrong exactly, but you are sure that the current setup won't allow you to be sure. You're faced with sitting in a situation where people expect you to validate a process, but you feel you can't - and so the only path is to resign.
However, as you can tell, there's a chance that the problem is the process verification team. Maybe they are dumb, or jerks, or whatever. If they are jerks, then you both wouldn't be able to rely on their specific accusations and it is possible that they missed things because of rudeness or incompetence, etc. So either way the sensible thing to do is not make specific accusations aside from "we don't think we can verify this process and we would recommend you take what others say about why with a grain of salt."
Moderating a community is not meant to entertain outsiders, but to prevent escalation within the community.
No offense, but what do you expect to be able to contribute to this situation as an outsider? Would your contribution to the community be improved by additional information?
They say in the post that they are open for Rust team members to discuss this. So the "insiders" would be Rust team members, I think there would be some hundreds of people. (There are multiple Rust teams, not just Core and Moderation.) Together, they also would have considerable power over the Core team, as the teams have some power in a do-o-cracy sense of the word.
I expect our contributions to the community would be improved by less information. When you're resigning from a position but you don't want to say why, you're supposed to gesture vaguely at personal obligations or career opportunities and leave it at that. "You guys should be mad, but we won't tell you why" makes it impossible for the organization to function. How can the core team lead the project or even appoint new moderators without putting this controversy to rest?
Exactly, this throws a giant spanner in the works and casts a shadow over whatever comes next. If they wanted to damage Rust in the eyes of the general public they couldn't have done a much more effective job. The lack of maturity on display must be particularly galling to those that give up a substantial chunk of their time to move Rust forward. Dirty laundry is best kept in-house, lest you damage the house.
> Exactly, this throws a giant spanner in the works and casts a shadow over whatever comes next.
Sometimes, throwing a spanner in the works is the good way forward. That's core to stop-the-line manufacturing, for instance. Without more information, it's hard to assess whether that team exhausted other escalation means, so I would wait for more details before judging their decision.
I'm not saying a post-mortem once the situation is resolved wouldn't be a good thing.
I'm saying that public awareness is not a priority while the issue isn't resolved, and that it may actually be detrimental.
> I might want to understand what's going on to understand if it's even worth it to be contributing to the community at all.
Usually, when moderation happens, information is best delayed until the problem is solved. That avoids uninvolved parties fanning flames on an ongoing conflict, and when information comes, it's structured rather than a stream of instant reactions.
Note that this is true whether the conflict finds a satisfactory resolution or not. If the team that leaves sees that no good resolution is found, they can disclose information later, once resolution attempts have been exhausted.
Note that this is from my past mod experience, I'm not involved in moderating the rust community.
This is true. Often people form opinions with limited information. We aren't sure what's true or what isn't true so without this information we should not logically even form an opinion.
The decision is "mature" if and only if what the moderation team claims to have occurred actually occurred, and we don't know the full details behind this.
This is a message from the moderation team to the Rust community that they've been moderating about the core devs. I would not expect it to be intelligible let alone accessible to "outsiders".
No, not every public information is written for everyone. Just because arxiv papers are publically available does not mean that a posted string theory paper should be written for you so that you can understand it (or I for that matter).
Nice example, arxiv papers (and any decent paper in general) contains an abstract to provide context about the contents of the papers as well as references to other papers cited within.
Arxiv papers might not be written for me now, but if I got interested in a paper (and had time to spare, of course) I would probably have most of the content I need to at least grasp the general content of the paper.
No offense, but you don't seem to have read many specialized scientific articles.
The time investment to even grasp the general idea of very specialized papers would be significantly longer than the investment you need to make to become a respected member of the rust community and apply for the next mod-team. Then you could also ask the members of the previous mod-team about the specifics of their complaints.
Maybe you are right, maybe the example fits perfectly.
Apologies, you are correct that was a snarkish response. I stand by my point though, we don't have any right to see "details" of the accusation. In particular the moderator team seems to resign not because of the particular case but because of structural issues. That is what they pointing towards.
Now regarding the structural issues, I actually could find very scarce information about the governance of Rust. I certainly could not find any information on how the core-team gets selected and what the processes are around being added or removed from the team. I also did not find much about their duties. So in that sense there seems to be verifiable information about lack of transparency (if not accountability).
Well, in the context of this discussion I interpret 'written for everyone' as 'author was aware that everyone can read this and still wrote what he wrote'.
An author of a paper on string theory published on arxive is aware that everyone can read it and almost no one will understand that except for a few from the intended audience. He or she is fine with that and so does everyone else.
The authors of the resignation letter are similarly aware of the publicity, but decided to go ahead with their vague and unsubstantiated accusations and their appeal not to believe if the accused party says anything. They are aware of the effect and are fine with that. Some people are not.
Yes? This is posted to the Rust Org's issue tracker: that is an appropriate place to post a resignation notice for an open org with heavy community interactions, and it's an appropriate place to inform the Rust community in general about their decision. That it happens to be public outside of those groups is beside the point. Do you often show up on Open Source projects complaining that their public scrum boards or pull requests don't document their entire decision-making process? Do you show up in people's IRC logs demanding that they provide context for everything they say?
The mod team isn't asking for public debate, they're informing the org about their resignation and briefly listing out why. They don't need to convince you of anything, they're just telling you what their decision already is. This isn't a persuasive essay, this is a notification.
I swear, this kind of "if anything is public, you're now suddenly accountable to me, and I should have full access to everything" attitude is exactly why so few organizations are open about any of their internal processes or decisions. It shows up in a lot of places: Open Source and game development in particular. Sometimes people have public conversations in forums/groups that are still intended for specific recipients. Sometimes people share a small part of a process or decision, and not all of it. Sometimes people muse about decisions openly, and their musings aren't intended to be a formal essay to be picked apart or debated. It's fine.
That's not the only thing that they did. As the Russian saying goes, 'if you said A, say B'. I'd have no problem with the message 'We are resigning because we had a conflict with a certain team and it didn't get resolved in our way', but they have said more, just enough to make a public accusation without any chance for the accused party to refute it.
The accused party can say anything they want, including airing out the relevant grievances in a more public way if they want to.
Giving someone the option of privacy is not the same as denying them justice. Quite the opposite, it's a mature way of allowing the org (and whichever people are involved in the incident in particular) to choose how public they want to be, and to choose how they want to respond.
But that's the extent of what they would owe, the mod team doesn't owe arbitrary people in the public an explanation that's detailed enough for them to form a hot-take immediately within the space of a few hours.
It was also posted by members of the outgoing mod team to the community subreddit and tagged with announcement, so it's not like someone outside this drama saw the ticket and decided to reshare it with a wider audience.
> to the community subreddit and tagged with announcement
I'm not sure this really changes anything, it is a community announcement. I think this is something a community would want to know even independent of any other drama, even if they were resigning on good terms.
I guess I should clarify that I don't see letting the community know about something as necessarily equivalent to volunteering to debate or even to fully explain. I don't think this stuff is a binary category between never intending a message be read by the public (even if it's technically public) and doing something like a national TV news interview. Rust has a community issue tracker/repo that it uses for organization; posting notifications there (and in other community hubs like Reddit) feels very appropriate to me.
(Aside: if the moderation team themselves treat pull request messages like a message board fit for announcements and general discussion, how good can they be at moderating? Making sure people stay on topic and post in the appropriate venue is something like a base-level expectation for even mediocre moderators.)
> This is a highly mature drama where the arguments are dry, generic and adhere to a strict code of values. No fingers were pointed, and the offended party is taking the high road by resigning.
As an outsider, I see Twitter-esque levels of grandstanding in the linked "post"—hardly mature. Based on observing the Rust community from afar over the last few years, this unfortunately is not something that is surprising.
(FWIW, I agree with all the comments pointing out that zero-context outsiders should not expect to be brought up to speed from a pull request message alone—anyone arguing the opposite is guilty of the same sort of mindset that I'm chiding here. If this announcement(!) weren't deliberately crafted to give the effect it does, supporters of the resigners might actually have a point. The fact that something that should be as boring as a pull request—no matter how controversial the subject—is being discussed in terms of "high roads" taken by any side, however, really throws that argument into the mud.)
Go hole up in a cabin in the woods and decompress by hacking on personal stuff or something and stay away from social media. For some, it has poisoned everything to the point that it has given rise to a new breed of vague status updates that pervade even project infrastructure.
It stems from seeing the people issues as small stuff and the tech issues as the "real deal"...
At the end of the day new features for popular language X are not that life-or-death (although I'm sure some Rust evangelist will claim the safety of it means it could save lives, ignoring things like MISRA)
-
If someone is being an asshole and damaging moral for real "meatspace" humans, that's way more of a problem than any loss of productivity that might result from dealing with them head on.
Contrary to popular belief, the world will not end if language X doesn't do Y right this second. So it's better to clean house as needed, rather than let things get to the point where everyone is burned out on interacting with your fiefdom .
Not so much ignoring, as recognising that much of what MISRA requires mechanically (ie that MISRA tools will let you check for a Continuous Integration setup automatically) is baked into Rust itself, and much of what MISRA asks beyond that is built into Rust's way of doing things.
My favourite this week: MISRA tells you never to use the result of an assignment operator. In Rust you can't because the assignment operators don't have a result.
MISRA goes further than Rust can and still be a widely useful language.
You'd need to define a very specific subset of Rust to approach its level of regulation and the additional layers added by ISO standards where it's often used
Do you have some examples of MISRA rules you think would need "a very specific subset of Rust" rather than for example, #![forbid(unused)] to obey MISRA's rejection of unused stuff ?
A lot of MISRA is concerned with defects in C - or in its standard library and the usual C idiom - that simply aren't present in Rust and so need zero work to eliminate. For example MISRA forbids trigraphs. Rust of course doesn't have trigraphs.
A bunch more is stuff Rust warns about, that you can tell it to outright forbid, such as #![forbid(unused)] to obey various MISRA rules about using things.
In a few places MISRA obliges you to either squint hard at the rules, or agree that it is contradictory and you must grant yourself a deviation from the rules, while Rust just solves the underlying conundrum entirely. For example MISRA wants exhaustive matching, it has rules for switches to try to achieve that but in the process it introduces dead code it has already forbidden. Rust only has exhaustive matching anyway - if your match compiles it was exhaustive - thus there is no need to introduce dead code "just in case".
Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc.
Rust might get the big stuff but MISRA is adhered to exactly in contexts where things that would be "nitpicky" or over-opinionated for a general use language improve safety. Pure Rust would never be a replacement for that without additional static analysis.
I asked you for some example rules, and you provided some
> Rules about identifiers for example, no shadowing, explicit typing only, no unused declarations etc.
#![forbid(clippy::shadow_reuse)]
... is a Clippy lint denying shadowing to re-use variables. There are a couple more Clippy lints to deny other types of shadowing. Whether all, some or none of these are actually a good idea depends whether your goal is to just do what MISRA says no matter, or actually write better code.
#![forbid(clippy::default_numeric_fallback)]
... is a lint requiring that you specifically say what type numbers are rather than relying on the inference to conclude they're i32 if there's no reason they should be anything else.
#![forbid(unused)]
... I already mentioned, it outright forbids your code from not using things, function parameters, variables, whatever.
If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea". I suppose this might help to rein in some "Real programmer" types at an embedded systems firm using C by giving their manager a tool that says e.g. no, actually redefining size_t is not a clever trick, but it means all those rules are entirely irrelevant for any modern language, not just Rust.
So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis... sure sounds like my initial point.
But that's not even the point.
> If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea".
This is exactly what I mean. You're missing the point of MISRA if you think that's an overestimation or just to make managers happy... MISRA is often for life or death, and it's not even going as far as the random ISO standards that end up applying on top of it in some domains. It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.
The ground work to even verify a Rust toolchain doesn't even exist, (the closest I could find is a WIP https://ferrous-systems.com/blog/sealed-rust-the-pitch/) so I'm guessing everyone forcing this is likely rolling their own setup of additional tools?
If you don't work on ABS controllers and you work at somewhere like Tesla where the bar for safety is a little lower in the name of using new shiny things, by all means use Rust. But I wouldn't do that in a million years. I simply don't buy that using established MISRA C tooling is less safe than rolling your own lint setup.
> So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis
Sure, if you consider Clippy "additional tooling" for Rust.
As I understand it, MISRA rules (those which are clearly decidable) are also not enforced by the compiler but instead require a separate toolchain, and not one that's supplied by default with your compiler either.
> But that's not even the point.
> [...] MISRA is often for life or death
It's far from clear whether MIRSA is "life or death". Some MISRA rules correlate well to serious programming mistakes, most not so much, but they do pad the MISRA ruleset which is commercially important. There have been real studies about this, they don't come away with the conclusion you seem to expect.
> It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.
This is half true. There are things that are a bad idea, which are easy in C and so real people will do them, and a few of these are caught by MISRA rules. None of those things is easy (many aren't even possible) to do in modern languages. Or indeed, in Ada. MISRA is a band aid on a hand C programmers have put through a band saw. "Let's not use C" is a better fix than "Let's use MISRA".
I mentioned the value of assignment as an example, clearly assignment shouldn't have a value, it doesn't in Ada, and it doesn't in Rust, or Swift. When your hypothetical "just human" developer tries to use the value of an assignment in C that works but in these other languages it won't compile. Whereas in C we need MISRA rules to forbid this bad idea.
Let's try another one. MISRA forbids declaring variables in the body of a switch. You can't do anything similar in languages like Rust or Ada because it's crazy. Nobody does it in C either, but they could and so MISRA forbids it just in case. But once again, MISRA isn't adding any real value here (except to tool sellers) by telling people not to do things that aren't done.
I can't speak to any of the "random ISO standards". To the extent they're trying to force C into being a reasonable language to write safety critical software it seems like a waste of time to me. If they're mostly about Software Engineering then that doesn't lose applicability when you switch to a better language.
As Amazon conspiracy theorist in chief, I doubt this is the case. Amazon likes to associate with good Rust PR, this is just messy stuff that takes away PR bandwidth and that makes things more unstable. People associated with AWS (eg Shane Miller, Chairwoman at the Rust Foundation and head of the AWS Rust team) will have to play a role in this conflict, and the decisions they will make should be publicly scrutinized, but that's it.
The source of this conflict seems a somewhat long-standing tension inside of the Rust organization.
You don't know what you talking about if you think the mod team is "petulant preteens" and not professionals who have moved the language forward in leaps and bounds.
As someone mentioned in another comment, BurntSushi is an amazing engineer who has contributed immensely to the ecosystem, on top of being a moderator. Don't turn this into some dumb "non-technical people stirring up trouble".
Since they don't say what happened, I can only speculate.
The usual CoC violation: probably someone in the Core Team made a statement (outside the Rust community and not speaking officially) that does not align with the progressive political thinking.
You say that the larger number of men in tech with respect to women might be due to biological reasons? CoC violation, fire the enemy of the people!
You say you voted for Trump? CoC violation, fire the enemy of the people!
You say only biological women are actual women? CoC violation, fire the enemy of the people!
When there was a huge push to adopt CoCs I warned everyone I knew about the clear potential for abuse by the leftist (who also incidentally happen to be the ones to back CoCs). In particular a CoC should cover only actions performed in a community, no-one should be banned to contributing to a project because of what they write on Twitter, for instance!
Absent some form of democracy, what does it mean for a leadership to be "accountable"?
Power extends from whoever has the authority to hold others to account. So this just reads like a power-grab from the moderation team. What would it mean for them to have the power to hold the core team to account? That they could sack people from it?
The goals of the project are set by the core team; not by a moderation team enforcing some abitrary CoC. Suppose a member who contributes 90% of new features to the project is "sacked" for an otherwise trivial CoC violation. This subsumes the project into an ideological purity-testing game.
Accountability here is just that the wider community has visibility on the actions of the core team, and will be up-in-arms if they are seriously unethical.
This is, in my reading, deeply bad press for the moderation team. The innuendo and insistence on their own power above that of the people leading the project... this "is a bad look".
EDIT: the immediate number of downvotes on this comment is interesting. I'd be interested in hearing from a down-voter on what their objection is.
It's not a power grab, because they just relinquished power, even going to the point of leaving instructions for the next group of people that would take over. Just this flaw in your logic probably landed you your first downvotes.
Second, the CoC is not arbitrary, there's a link to it merged into the repository which means the core team (or at least a majority of it) agreed to it. Their resigning is just a signal that the CoC that they publicly announce is not actually being followed. It's nothing more than that.
For a leadership to be accountable means that they follow the rules of the system, and should they not follow them they are ejected from it. It's as simple as that, no need for democracy, the system is clearly defined and agreed upon.
I don't really get what you mean with "a bad look" for the moderation team. It's a bad look in the sense that it shows they actually had no power all along. But I don't think they were in it for the glory. A worse look is that of the core team, who have publicly stated their support of a CoC, and now when shit hit the fan show they won't actually abide by their own rules.
Sure, in round one, they've resigned. Games are played over multiple rounds. We're yet to see how it plays out.
Though I don't really expect those individuals to comeback, this may well just be a move to subsume the projects "technical goals" (ie., those of the core team) under the "ethical goals" of the moderation team. As a technical project, to me, this isnt that sensible.
> leadership to be accountable means that they follow the rules of the system
This misunderstands power. There are no (enforced) rules prior to power. Power is the mechanism by which there are rules. This resignation isn't to establish rules in the abstract -- the CoC exists. Its for a team to have the power to enforce them.
And "Rules" here arent rules at all. They are principals. And pricipals trade-off against each other, and against other goals. When we say the core team has "agreed" that does not imply theyve agreed to all views the moderation team takes.
I have no idea who is in the "right", to be clear, on the ethical issue. Perhaps a member of the core team has done something severely unethical (in which case, presumably the ethical thing to do is tell people...). However the phrasing of this as an explicit demand for power... to me reads a little off.
It reads like they wish to be part of a project where an ethical ideology reins decisively above the technical goals.
Eg., consider the core team will give a member "more latitude" to, say, rehabilitate if they've done something wrong. You might say they shouldnt. But it this a technical project, or a political-ethical one? Are its leaders meant to be morally excellent or excellent software developers?
The reality is that technical projects require technical excellence, not moral excellence. A "moderation team" set-up to demand moral excellence can easily go too far and ruin a project. Of course, if a core member is deeply unethical one hopes the community & core-team will do something about it.
My sense here is that if someone was "deeply unethical" they can be held to account by telling people about it. And if they weren't, then I imagine the core team have made the right decision for the project.
No, but when you resign you are no longer in a position to influence anything. Resignation is an act of last resort, you throw yourself on your sword in the hope that someone notices and that's that. You can do it exactly once.
Until this has been completely cleared up I highly doubt these moderators will be welcome anywhere else. For now they are almost (but not quite) as tainted as the core team because there is of course a chance that the core team is right and they are wrong.
>It's not a power grab, because they just relinquished power
Relinquished what power? If they had said power, surely they would have gotten their way yes? Perhaps this is just an incremental iteration of the ongoing fight for power, a last ditch effort to get public sentiment behind them.
>agreed to it
This could have been a tactical choice to avoid fighting head on in that battle, waging the larger war against the CoC by simply ignoring it over time. It is just as likely to assume many who "agreed" to it didn't really agree with it, evidenced by them not following it. And here we are, it seems these people have "won" as they didn't follow it and the the team pushing it/enforcing it lost. So perhaps this strategy was the optimal one. "Agree" to a thing to move on with more important matters and ignore those who nominally are tasked with enforcing it but have no real power, if ignored.
If this wasn't about power, they wouldn't be airing their dirty laundry in public. The only reason you do that is because you're hoping to stir up some sort of shitstorm to (threaten to) damage the public perception of the project. It's juvenile he-said-she-said behavior that's barely above storming to your bedroom shouting "screw you, mom!" and slamming the door so hard a few shingles fall off the roof.
Of course what you inevitably get isn't an internet shitstorm at all, but a bunch of rubberneckers gleefully gawking at the high school drama publicly unfolding in your organization.
> the immediate number of downvotes on this comment is interesting. I'd be interested in hearing from a down-voter on what their objection is
Did you edit your comment at some point after publishing to be a little more mild (e.g. remove the word "childish" or something)? I apparently downvoted you at some point, although I don't see anything currently in your comment that would have caused me to do that.
I'm not sure where I land on COC-style stuff myself, but I have zero patience for people who are insulting to those in favor of them with words like "childish." If you had something like that in your comment at one point, I would have downvoted it. (TBH your comment is borderline with claiming COCs are "arbitrary," but I wouldn't have downvoted just for that.)
Thank you for your reply. I did make a minor edit for tone, but I only added my downvote-edit when several downvotes came in after this -- as I then assumed it was a content issue.
Fixing poor tone is definitely great, although I suggest if you edit, then make that clear, as otherwise you confuse people and people will silently assume you are acting in bad faith.
Note that I often downvote any mention of the word “downvote”: I am sure you asked in good faith, but as a sweeping generalisation, commenting on voting doesn’t improve conversation. Not knowing why you get downvotes is a “make you think” feature IMHO. I also believe excessively caring about votes is a red flag: some of the best commenters seem to be fairly neutral about caring what the HN voters think.
Not trying to start a conversation about voting and maybe my comment deserves downvotes. I am answering your implied question about why you might get a downvote even after your corrections to “tone”.
> I'd be interested in hearing from a down-voter on what their objection is.
Firstly, you alleged the mod team was engaging in a "power grab" by resigning immediately. Others have pointed out that is illogical. At best a resignation could earn them some level of sympathy, but it eliminates their current power along with any potential for them to acquire power in the future. If there is any way for the mod team's resignation to increase there power, you have not shared it.
Secondly, your claim seems to be baseless. Nobody in this HN thread has shared any details beyond what is in the resignation PR - much less enough to suggest a power grab. I consider baseless allegations like that to be harmful to the overall discussion. Until additional details regarding the conflict are made public, we should not encourage people to form character judgements on either party.
Of the CoC is written and approved by the core team, then I see no issue with enforcement being delegated to a mod team. That’s no different to having separate judicial and legislative bodies. One writes the rules, the other enforces them, including enforcing them against the authors of such rules.
While the core team could modify the CoC to make their non-compliant behaviour compliant, that would require them to effectively admit to engaging in behaviour that violates the CoC. The rest of the community can vote with their feet on if they believe the CoC is fair, and equally if they believe modifications are fair. But importantly all of these changes happen out in open where they can be scrutinised.
> Suppose a member who contributes 90% of new features to the project is "sacked" for an otherwise trivial CoC violation. This subsumes the project into an ideological purity-testing game.
Punishment doesn’t have to be all or nothing. A CoC can provide guidance on how moderation is performed, and how punishment is meted out. The CoC should be equally binding on the mod team, as it is anyone else, and the mod team should seek to ensure due process or face replacement.
> Accountability here is just that the wider community has visibility on the actions of the core team, and will be up-in-arms if they are seriously unethical.
We don’t know the nature of the offence. It quite possible that the victim or victims have requested that the nature of the offence is kept private to prevent retaliation from others. For the mod team to publicly list the offence might cause more injury to the already injured parties.
> The innuendo and insistence on their own power above that of the people leading the project... this "is a bad look".
If the CoC delegates power of enforcement to them, and CoC has been agreed to by the core team, then the mod team does have power over the core team. But importantly, only in matters covered by the CoC. Just like how members of congress are still subject to law enforcement by the police (or should be).
It means the leadership is willing to accept responsibility, not just accepting negative feedback but also working with others to correct the behaviors. In this case I would say it would involve admitting a violation happened and to say what will be done differently in the future.
I can see how this can be extremely complicated, depending on the type of CoC violation people tend to be extremists, forget about being constructive (to assume good intentions) and immediately grab the pitchforks.
> The goals of the project are set by the core team; not by a moderation team enforcing some abitrary CoC.
It's dishonest to publish a CoC that -- silently -- doesn't apply to those with power. Why does that matter?
Don't forget that a language with a strong core team but no community of users, contributors, documenters, enthusiasts, etc., is hardly more than nothing -- people making specifications that aren't implemented and if implemented, not used.
The purpose of a CoC is to set ground rules to allow the community around the language -- the community that must exist for the language to have any real value or purpose -- to grow as strong as possible.
You're granting the core team all the power in rust, but they are kings of very little if people don't chose to adopt rust.
Some people or companies may choose to invest -- or not invest -- in rust based at least partially on the code of conduct.
Other people may choose to invest -- or not invest -- in rust based at least partially on their confidence in the long-term capability of the core team. Does "accountable to no one" instill that confidence?
Also: you really are misunderstanding what the mod team did here. Resigning is a single-shot ploy. There's literally nothing left that they can do. Whether this is a "bad look" for them is entirely irrelevant.
At this point the rust core team has to decide if they would prefer to more forward with or without a code of conduct, and whether they will be honest about it or not.
The rest of us can watch and decide if/how we'd like to continue to participate with rust. Those making long term plans should watch especially carefully.
Well, you either have a explicit hierarchy of people working on something, and then the people who are a part of the "top layer" can sometimes start to look down on the ones who belong to the layer below, seeing them as less knowledgeable or not producing useful output. Sometimes that leads to people starting to close down into their current layer, and forms "us-vs-them" groups. Or, you have a implicit hierarchy and basically the same thing happen but the layers don't have names.
> "top layer" can sometimes start to look down on the ones who belong to the layer below, seeing them as less knowledgeable or not producing useful output
So? Are you going to blame them for seeing the reality as it truly is?
Equally well read as "all others are non-essential" -- tantamount to "subordinate". Guaranteed to seed resentments among those outside the "core".
The social fix would be to change the name "Core" to "Base Language" or some such. Perhaps fork off a separate "Ecosystem" committee with broader representation.
Bona fide: Was once myself on the other side of a "Core" team boundary.
Almost anything in the real world that works and is not dysfunctional is built on hierarchies. Where hierarchies are not explicitly spelled out they are implicit and without accountability - "some animals are more equal than others".
How to promote on merit and not nepotism or corruption is the hard problem.
Thinking they can be separated long term is very naive.
First, competence itself is subjective and hard to measure, especially for the very broad task of language design and stewardship. Which skills and credentials are considered most relevant and who's judging them is already "political" (e.g. do "hackers" get stuff done, or are winging it? Is someone with a PhD in PLT the most qualified, or an ivory-tower academic?)
Then there are human factors. Programmers aren't deterministic stateless coffee2code transformers.
Some people will dislike other people, for a broad range of reasons that may be valid or not, and that will affect their judgement. Also many projects and companies have to deal with "asshole geniuses". It's very "political" to decide whether you kick out someone who writes good code, but scares away other contributors.
"Corporate politics" is not thing set up on purpose, but it's a meta-game that emerges even in organizations that are supposed to be purely meritocratic. There are people who will consciously play this game, and have an advantage over people who naively think the game doesn't exist (I'm not endorsing it, but saying it's a phenomenon that orgs need to be aware of and actively deal with instead of declaring they're apolitical).
Who would want to see Rust move to a DAO on blockchain? I can help make that happen. ray@oblivion.io
Since so many blockchain projects are using Rust and the community is struggling perhaps moving it to a DAO is the way to reboot things and create a more democratic and transparent experience for all.
Of course, it's not known what really went on internally, but something like this doesn't really come as a surprise.
This is what you can expect when you put people with a questionable history of adhering to CoCs or are activists rather than developers in critical leadership positions.
Good. If Rust's management falls apart, the language will become more decentralized, like it should be. I was always very, very nervous having a systems language totally controlled by only one organization. Hopefully this will result in a fork of rustc and some new interest in gccrs.
The problem with decentralization as nice as it sounds is a decentralized group of people doesn't pick up all the work that is done by the core person/group. If that person or group is no longer doing a good job, a competing person or group can fork the project.
Moderators are nothing. Developers are everything. Moderators can resign all they want. The important thing is that developers do not resign. Those CoCs are getting out of hand. It was a terrible idea from the start.
BurntSushi (who made the PR) while also being a moderate is more widely known of his technical excellence and grate contributions, like the regex crate and ripgrep.
Developer do resign over non technical topics, no one wants to contribute to a project where they don't feel welcome.
Toxicity in the internet is getting out of hand, CoCs are just a consequence of this.
It's basically impossible to run a larger community without a CoC (weather or not it's written down or implied). I have yet to see any larger community which doesn't have a CoC and doesn't has problems with toxicity, sexism and/or discrimination.
I have seen more then one or two highly talented people leaving the tech sector because of them encountering too much toxicity, sexism and/or discrimination on their first
contacts with the sector (both open source and in companies).
> 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