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).
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 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.
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.
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.
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.
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?
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?
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.
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.
> 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.
Being a man I don't see how anyone would feel unsafe by a prominent Core team member advocating for all men to be killed.
> 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 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.
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.
> 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.
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.
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.
> 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.
> 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.
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.
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.
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?
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.
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.
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.
>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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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 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".
"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.
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.
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.
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.
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 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."
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.
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?
>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.
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.
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.
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 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.
> 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.
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…
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?
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”
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.
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)
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".
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.)
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.
No. Guessing they were self-elected. The fact that they won’t disclose what the issue is or the nature of the issue, it’s likely they were being little whiney kids.
To me, it looks like moderators somehow want to usurp power that the ACTUAL devs should have.
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
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"
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.
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.
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.
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.
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.
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.
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.
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. If not, your entire organization is cowardly and hiding behind a scapegoat and mouthpiece.
> 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 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.
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.
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.
> 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.
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?
He changed his tone, he wasn't "cancelled" as how it is a fad to do today. There are no "cocs" for a very long time now. It's only after pandering to the SJW's that are unfortunately causing harm to everything they touch.
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.)
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).
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.
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.
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.
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 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.
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.
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.
> 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.
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 have never seen that on the table to be honest, certainly not on implementation language topics. There was some uncertainty with Java and licencing that I remember, but it is mostly about the issue on how to acquire talent.
People tend to be careful with Rust because it is a relatively young language. Many medium sized business don't have much capacity to experiment but would still try it without too much convincing.
Far more relevant it access to professionals that have experience with the language. That is something that grows very slowly. The JS community is pretty "expressive", but it is still a popular choice because you find a lot of people with experience here. My boss would expect all these nerds to behave badly anyway. I doubt he will ever change his opinion but the next generation might.
I 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.
These organizational breakdowns in tech communities (recently Rust,.NET, Elm) make me much more appreciative of long-running, relatively healthy communities.
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.
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.
> 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...
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.
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.
Does this moderation team even contributes to the code base to feel that the members of the core team have to adapt to follow some stupid code of conduct?
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).
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.)
To give folks who are privileged and well connected but have not put in the time and effort to be able to make technical contributions a chance to put participation in a trendy OSS community on their resume.
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.
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.
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.
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.
We don't contribute but we want control -- if we can't have it, we will libel the project.
Almost every open source project is being overtaken by social justice warrior leeches. Even Linus Torvalds was kicked out of Linux. I'm surprised that the Rust community pushed back.
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]
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.
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?
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?
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.
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'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.
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
> 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.
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.
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!)
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.
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.
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.
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.
My guess is that someone who seeks out a position on a "mod team" is the type of person who cares more about controlling others than doing interesting technical work.
The success of Rust is not of concern. The control is.
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.
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.
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.
Well this person is on the core team and has said many horrible things in the past and so it's possible this is indicative of the culture of members of the core team. https://archive.md/VEtHu (from 2017)
But this is trying to imply that past crimes are evidence of future crimes, which I'm not a huge fan of, so take it with a grain of salt. But it's a useful data point at least for me.
> 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.
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.
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.
It’s not the number of search results, but the frequency of events. Admittedly, there isn’t anyone aggregating events and I only looked for the most recent 3 before stopping. I’m sure there’s some insider who’s better positioned to tell the history of the language and the community.
I 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:
No kidding. It’s not a curated dataset, obviously. I looked through a few pages and filtered out the most recent few actual dramas:
1) Rust in the Linux kernel
2) Amazon MUST NOT define Rust
3) Turbofish issue
So, yeah, you have to do a bit more work to pull events from Algolia. It’s better than a feeling though and it’s real timestamped data. It’s not Google or Wikipedia though- the most relevant results aren’t just on page 1.
I 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.
> 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.
> 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 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.
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.
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.
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”.
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.
> 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.
> 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.
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.
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.
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).
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.
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).
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.
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 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".
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.
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"
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.
> 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."
(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.
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.
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.
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.
> 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 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
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 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.
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.
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.
> 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.
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?
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.
910 comments
[ 4.1 ms ] story [ 189 ms ] threadSo? Are you going to blame them for seeing the reality as it truly is?
> Managing the overall direction of Rust, subteam leadership, and any cross-cutting issues
This sounds to be more of an "executive team", but I am also unfamiliar with Rust development, so I don't know how accurate that is in practice.
0: https://www.rust-lang.org/governance/teams/core
"Language Design Team"
"Compiler/Roslyn Team(?)"
"CLR Team(?)" yada yada
so more product/role-driven naming schema
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.
You are saying it like as if it were something bad.
How to promote on merit and not nepotism or corruption is the hard problem.
That's the question our society is facing.
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).
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.
(Edit: oh, perhaps tangentially related after all. See codys' comment https://news.ycombinator.com/item?id=29307113)
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.
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.
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.
There would seem to be a massive conflict of interest there, if true.
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.
Being a man I don't see how anyone would feel unsafe by a prominent Core team member advocating for all men to be killed.
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 guess the speculation is around whether or not she is the core member that might be causing friction with the coc.
Not part of the general Rust community, just an outsider, so maybe I'm missing something obvious.
> 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?
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.
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.
This stinks. I wonder if the moderators are concerned they'll be found culpable as well, if the problem is revealed.
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.
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.
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.
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.
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.
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.
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.
But for some reason, the formalization of conduct enforcement stuff around OSS projects still feels weird, off-putting, and very "Corporate HR"-y to me. I still get a kinda awkward feeling every time I see a code of conduct in a freaking code repository as opposed to an MOTD or mailing list welcome email or the like. The contents is normally reasonable and if it were in one of those other formats it'd feel normal, but checked into a code repo just feels wildly out of place and needlessly in-your-face?
Maybe I'm just getting old.
Edit: it looks like you've removed the part about Teams/Committees.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
If this "moderation team" felt that there is no option but to quit, that means that they were rejected by the community, complete with the "CoC" they tried to enforce.
Seems like everything is fine to me.
Repositories for most projects are more project repositories than mere code repositories.
Indeed, but for some reason it still feels odd. I've acknowledged I'm getting old, right? ;-)
Also, there is some rational justification to my feeling. It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contributions. But if they made a technically meritorious merge request via SCM the contribution would still get due consideration. Even assholes can be good programmers, after all. That always felt healthy & mature to me. Finding a way to protect the masses from assholes without exiling the asshole always felt like a sign of good community stewardship. It's something I strived to do in communities I moderated.
So, what? I guess this: Bundling the CoC into the repo violates this expectation. Just because someone couldn't get along doesn't mean we kick them out of the hobby. I think that's why it makes me uncomfortable.
In a hobby org, you don't let the known jerk on the board. You definitely don't let him man the booth at community outreach events! However, you also don't usually kick him out of the core activity. In a non-OSS hobby context, I've had folks steal things but still allowed them to stay in the community while taking away unsupervised physical access to common property. Measured tolerance and forgiveness are both important virtues, and sticking around in a community after public humiliation shows a commendable level of commitment to the hobby/community. The social bonding that happens via the process of apology and forgiveness often does far more good for the community than the harm of the infraction.
But, also, I've always considered OSS a hobby scene rather than a business model or resume booster. I guess if an OSS project is just a way for companies to commodify complements and for contributors to get jobs, then treating it like a Fortune 500 all-hands makes sense. But I'm not interested in those types of communities; I have hobbies, and programming can be a hobby for me, but I charge a lot for my labor and would never, ever work in a corporate environment for free.
I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are.
Again, getting old I guess.
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.
> 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.
That seems like a pretty significant design flaw :(
> Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation [between "community" and "code"]
Indeed, this makes perfect sense.
> It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job.
Yup, totally fair and makes sense.
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.
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.
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've heard that large-scale enforcement of CoC is super easy and that all the big social media companies have it figured out ;-)
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.
Also, is it common for projects to have mod teams? This is new to me.
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.
[1]: https://www.rust-lang.org/governance/teams/moderation
What is the reason that amazon folks would want to try and harm the rust core team?
Is there a specific group of "amazon folks" you're talking about, or do you think the entire company has something against the rust core team?
(Not saying they don't, I'm just slightly perplexed and have no idea what you're talking about).
The source of this conflict seems a somewhat long-standing tension inside of the Rust organization.
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?
https://github.com/rust-lang/team/blob/master/teams/mods.tom...
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.
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".
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".
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.
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?).
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.
Don’t be half assed about it. Ya’ll wanna air it out, air it out.
https://reddit.com/r/NotLikeTheOtherGirls
So some people are particularly special, huh? I doubt it.
We are professionals - I'm not going to get involved in playground politics.
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.
>not going to get involved
Getting involved or not are both political acts.
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 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."
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.
What would you have done in that case?
They did: What went wrong was that the mod team doesn't have the power to mod the core team.
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.
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.
* 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.
>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.
"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!"
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.
Nobody resigns over a theoretical flaw in the governance structure. It’s only when it starts becoming a problem that people do so.
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…
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 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”
Either let the public in on the situation or don’t. Don’t badmouth someone and then refuse to explain why.
Do you need specific instances, date and timestamped?
Edit:
If it helps, imagine a time you quit your job.
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'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.
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!"
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.
What I read does not seem to fit this definition, but maybe to others it does.
> To harass or punish in a manner designed to injure, grieve, or afflict
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.
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)
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.
I'd give the mod team the benefit of the doubt that the offense they've all resigned over is not so mild that it could be committed unintentionally.
I don't think that's necessarily a safe assumption, particularly in today's cultural and political environment.
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).
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.
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.
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.
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?
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.)
I wouldn't say so it basically says:
Let's keep past thinks in the past.
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.
To me, it looks like moderators somehow want to usurp power that the ACTUAL devs should have.
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
EDIT: it's remarkable that there's none, aside of "someone said something"
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)
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.
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.
It's almost as though software development skills aren't correlated with social skills...
We have significant, documented evidence of assholes producing world changing software.
We can’t do the same for the inverse personality type, can we?
I’d rather have amazing open source free software than the validation of a blue check mark.
Not unless you discount the idea that it could be even better software if those people hadn't been turned away...
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.
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.
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.
100 years from now, people will recognize the name "Linux Torvalds". Who will remember the tone police?
Linux is a major accomplishment and a boon for all humanity. All I see the hall monitors accomplishing is the production of drama.
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.
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.
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.
>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.
https://www.inc.com/tess-townsend/why-it-matters-that-an-obs...
You're upset that a Eugenics-lite writer was almost banned from a conference?
Not evil, an exaggeration but still: would you want to be in the presence of some body so bigoted? Who thought you inferior because because because?
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.
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.
See also LambdaConf's conclusion on why they should allow him to participate anyway: https://degoes.net/articles/lambdaconf-inclusion I agree with this article fully.
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.
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. If not, your entire organization is cowardly and hiding behind a scapegoat and mouthpiece.
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.
It sounds like we just have a difference in moral standards.
Well - at least if I ever run a conference, you can be confident that you will be welcome to it anyways. :)
Even when it comes to unpleasant people like Moldbug I try to avoid talk of moral standards beyond the really clear-cut ones...
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.
Mauro, SHUT THE FUCK UP!
Yeah, and probably exactly like that.
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.
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).
I know very little about NetBSD and am a great fan of OpenBSD.
But Theo is a very horrible person who often attacks people in a personal way for disagreeing with him. I got into a stupid argument with him over fundraising - a subject where I have deep experience - and it was quite bizarre. He had a set of assumptions and disagreeing with them got abuse from him, and some of his minions on the OpenBSD-Misc list, and (I was astonished) abuse in my INBOX from throw away accounts.
What an arsewipe!
Your counter examples are questionable at best.
Anyway, regarding Richard Stallman and those accusations of “various kinds of sexual misconduct”:
https://sterling-archermedes.github.io/
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.
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.)
I don't think this is a fair counter example, he's been accused for expressing personal opinions, on his personal blog.
The accusations led to nothing.
Linus changed his tones just recently, now that he's older and have children, the "previous version" of Linus brought Linux to where it is though.
He's still very harsh when things get highly technical, because he's one of the few people that know at heart what's best for Linux.
sex - sure, but gender? we got plenty of females in OSS!
Still a general underrep of women.
e: Oh I see - your comment wasn't in good faith at all.
not just yours :)
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.
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.
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.
You have now painted a target on your project, every activist that finds your CoC in non-compliance now has:
1) a means to proposition your submission
2) a cudgel to bang you with should you reject #1
A far saner solution is to ban CoC and those who request a CoC. The CoC then becomes “don’t request a CoC”. Tolerance paradox in action.
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.
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.
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.
https://github.com/domgetter/NCoC
Like this person being the executive director? https://archive.fo/f10KK
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.
Meanwhile, above ground, JavaScript, Ruby, Haskell, and Scala all have worse reputations than Rust.
Setting up little etiquette kangaroo courts with the power to arbitrate who is allowed to remain in the community is just fundamentally alienating.
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.
Remaining small and consistent is still a nobel goal, but new features can be a boon to the community.
What do you do indeed?
Everything but writing a formal specification for some reason.
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.
> 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.
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.
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?
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.
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).
https://lists.isocpp.org/mailman/listinfo.cgi/
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.)
Nearly led == did not lead. So nothing happened?
Almost every open source project is being overtaken by social justice warrior leeches. Even Linus Torvalds was kicked out of Linux. I'm surprised that the Rust community pushed back.
No. The downvotes probably come from the bullshit lies you're spewing:
> Almost every open source project is being overtaken by social justice warrior leeches.
False. Or at least it has to be assumed false until you back it up with numbers.
> Even Linus Torvalds was kicked out of Linux
False. Obvious lies.
> I'm surprised that the Rust community pushed back.
What?
How are team members selected? Who has authority to kick someone off a team? How are team leads selected? Who can remove team leads?
Is it the core team? If so, who picks the core team?
I can't find anything online, except this very bare-bones WIP stub. [1]
This seems to be a glaring and surprising oversight.
Especially at this point, with Rust becoming more and more popular, the foundation in place for almost a year, and corporate interest flooding into the project, I would have expected proper procedures to already be in place for quite some time.
There certainly seem to be other cracks in the system. See for example "I refuse to let Amazon define Rust" by core team member Steve Klabnik, extensively discussed here on HN. [2]
[1] https://github.com/rust-lang/governance/blob/master/common/m...
[2] https://news.ycombinator.com/item?id=28513130
Rust however wanted something different and attracted a lot of "snowflakes" because of it.
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?)
I'm genuinely curious, maybe I misunderstand what it means to be offended.
And it's almost always advocated by people who have the upper hand in their own exchanges. Which is fascinating, isn't it?
The alternative we're seeing is an ever-expanding, ever-blurring definition of what is policed as "offensive", stifling innovation and fostering division.
As someone said, reasonably, that we have a system of law and order. If someone threatens you with violence, call the police.
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?
> 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.
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?
Because I have important stuff in my life that depends on it; business, workflows at work, IT infrastructure, ...
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.
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.
p.s. pronouns used are from https://www.orionsarm.com/eg-article/495360fba7a46 , I don't think singular they is correct thing.
It doesn't sound like they directly work on the compiler?
Maybe the problem wasn't Amazon, and HN shouldn't have jumped to conclusions so quickly...
But seems like there is a new drama every week with the core team and community.
That's what happens when you elevate micromanagement of language to a task of equal or greater importance than the creation of code.
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.
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.
Same happened with Node as it gained popularity.
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.
We still don't know what is going on.
> 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
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.)
> 'wie A zegt moet ook B zeggen'.
Someone else mentioned "the Russian proverb, 'If you've said A, say B'"... In Swedish it's "Har man sagt A får man säga B". Seems rather international.
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.
The success of Rust is not of concern. The control is.
> Subteam, and especially core team members are also held to a high standard of behavior. Part of the reason to separate the moderation subteam is to ensure that CoC violations by Rust's leadership be addressed through the same independent body of moderators.
https://rust-lang.github.io/rfcs/1068-rust-governance.html
Fantastic.
One would struggle to find more than a handful of people who have done more "actual work" for Rust than Andrew.
[1]: https://blog.burntsushi.net/about
[2]: https://github.com/BurntSushi/ripgrep
[3]: https://github.com/rust-lang/regex
[4]: https://github.com/BurntSushi/byteorder
[5]: https://crates.io/crates?sort=recent-downloads
https://github.com/BurntSushi/toml
https://github.com/BurntSushi/xgb
https://github.com/BurntSushi/wingo
But this is trying to imply that past crimes are evidence of future crimes, which I'm not a huge fan of, so take it with a grain of salt. But it's a useful data point at least for me.
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.
Disclosure: I am an outside observer, and I find Rust to be excessively syntax dense. Take my opinion with a grain of salt.
Between Oct 2018 and Oct 2021...
https://hn.algolia.com/?dateEnd=1635638400&dateRange=custom&...
"So, upon hearing that the .net foundation is spending all of its time generating stacks of bureaucracy and causing internal drama"
"Oracle provides RHEL build and it's pretty good. No CentOS drama, it's free and just works."
"I'd be surprised if you found any dramas with the language."
There's no actual drama. Until page 4, when i find:
"Completely a drama"
In an article about Rust.
But I remember a lot of drama on Ruby and Rust.
First comment is referring to something that happened years ago.
Second comment isn't about Rust at all.
Third post is about Steve not liking something that came out of Amazon.
Reading on it appears to be more references to Actix, Amazon, totally unrelated/ irrelevant results, etc.
1) Rust in the Linux kernel 2) Amazon MUST NOT define Rust 3) Turbofish issue
So, yeah, you have to do a bit more work to pull events from Algolia. It’s better than a feeling though and it’s real timestamped data. It’s not Google or Wikipedia though- the most relevant results aren’t just on page 1.
I believe that would very quickly kill the community. Corporate MS cannot be patron here. You will never find me in a development community that puts compliance over people. I accept that in my job because it makes sense there and is necessary. But there are current sensibilities about conduct I do not share and I am not ready to keep up with the newest etiquette to be honest. I think moderators should go against obvious trolls and spammers, but aren't fit to mediate in conflicts.
HN has a strong moderation, but I think these are rules that the community accepts because everyone profits. It could just be a power grab by some mods that feel neglected, at least that is what they seem to display here.
I 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
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.
It is like HR staging a coup d'etat.
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.
>burntsushi ripgrep · rust 31 points 2 hours ago
>If we had an answer to your implied question it will necessarily reveal things (via obvious logical inferences) that we carefully avoided revealing in our statement.
https://old.reddit.com/r/rust/comments/qzme1z/moderation_tea...
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.
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.
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.
That may be so, but these people are no longer playing the game.
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.
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.
People don’t distinguish between earned power(authority ) and unearned power anymore.
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.)
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”.
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).
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.
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.
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.
I'm confused as to whether I should care or not. If there are consequences on the tech, people need to spell that out.
Right now this all seems like some middle-school playground emotional drama. I'm too old to care about that.
It's not often that people behave in a mature fashion, so I fully understand you did not recognise it for what it is.
I have no way of forming an idea whether it's utter bs or if there is something actually going wrong.
And I'm sure that the authors of the message are aware of that but made the decision to write what they have written anyway.
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.
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.
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.
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.
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.
Thanks for the example, it fits perfectly.
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.
My point is that arxiv papers (like most papers) come with an abstract to set the stage and have references to other papers cited therein.
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).
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.
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?
Who are the "insiders" here? A couple dozen people?
Rust is supposed to cater to their user base, not the dramas of a few people who need attention and something to do with their life.
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.
That's a pointless question.
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.
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.
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.
That's not what they did, obviously.
The statement is much more than that.
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.
More importantly this is a problem in a private organization and not a public entity or court proceeding.
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.
> 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.
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.
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 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?
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.
(How can any of this be so hard to understand???)
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.
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."
> 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.
This appears to be a big win for the rust community.
Absolutely everything about this team’s behavior is mature and reasoned.
> This appears to be a big win for the rust community.
This appears to show that you have absolutely no idea what this is about.
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 .
My comment is vague because this is a common line of thought:
"Project X is having people problems"
"What is this childish drama distracting from the technical stuff they should be accomplishing"
-
Their post is vague because they're mature enough to not want to turn this into a public lynching. It's on their replacements to handle it.
There's a certain irony in the fact you don't realize that...
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.
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
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.
> 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.
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.
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.
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.
A resignation is a public action, and as this team knows very well, such actions need to be held to account.
"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 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?
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.
They did have the option of finding replacements before leaving.
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.
> we wish to ... focus on Constructive Criticism: how to improve the state of things, moving forward.
> There are many potential topics that are worth exploring: > What should the Rust Governance look like?
> How should the Rust Moderation Team be structured? What should be its responsibilities?
> How can we ensure accountability and integrity at the top? Who Watches The Watchers?
and I don't see how these can be meaningfully discussed by someone who doesn't know what went wrong. You can't diagnose and find a remedy for a problem that you can't even see. So while the sentiment "let's talk constructively" is fine, in public at least it seems like a non-starter.
Note that I'm not saying that this means they should publish a tell-all either -- but it needs to be recognized that, without that openness, the divide between insiders and outsiders remains. And the outsiders can't do anything constructive about these questions.
[0]:https://www.reddit.com/r/rust/comments/qzme1z/moderation_tea...
The "what went wrong" appears to be an organizational dispute, at least if we're to believe the statement.
Moderation team wanted authority over the core team. Core team disagreed. Moderation team resigned.
It's not clear that there was a violation, though their intentional vagueness does tend to push the reader to that assumption.
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.
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 makes it very clear that they had some specific grievances beyond unaccountability, otherwise it wouldn't sense to say they've avoided airing them.