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.
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 ;-)
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.
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.