People who are ostracized by projects with a Code of Conduct.
Or, to put it another way, if you're a jerk and you argue with other contributors about an on-topic issue in a jerky way, then under a Code of Merit, you still come out on top as long as you're technically correct (the best kind of correct!), even if it leaves other contributors feeling put down.
Granted, there is some overlap. For example, both the Code of Merit and most codes of conduct disallow disparaging remarks based on protected characteristics. But the Code of Merit disallows them because they're considered irrelevant to the project, whereas codes of conduct disallow them because they're affronts to dignity.
I do take issue with many codes of conduct in the tech space, because I think they tend to be written in a bubble world where everyone assumes that everyone else thinks just like them, but a Code of Merit sounds like it's even more problematic.
I take issue with them because a Codes of Conduct doesn't make a space safe. And also because if we need a written list of what behaviour is tolerated, we have a much greater problem than a code of conduct will solve.
I've seen people write about the former; I haven't about the latter. I find a CoC offputting because it equates me with the lowest of the low. It says I can't be trusted to behave like a decent human being and need to be told what's right and what's wrong, like being back at school.
I also see it as darker than "assumes that everyone else thinks just like them". Some - not all - are about controlling the world into the form the CoC proponent(s) want it to be. The CoC goes beyond its words and into society.
Neither do I support the Meritocracy thing, as I've had it used on me too many times by people who are super-smart and see that as a reason to be jerks.
Do you have the same reaction to automated linters or being told to write unit tests? What about the enforcement sections of the GPL? I mean, you, not being the lowest of the low, aren't going to write buggy code or reuse software unfairly, right? Isn't it an insult for people to imply that you might?
Do you leave your door unlocked and your keys in your car? If not, aren't you assuming that there are some people out there who can't be trusted? If I come to your house and find it locked, should I be insulted that you've not "trusted me to behave like a decent human being"?
There are a lot of very intelligent people who see problems with society and critique society, but society doesn't like that much. Intelligent people do very good work and tend to get along with other people who think deeply.
If an affront to dignity is simply a well thought out critique or parody of society, I can see Code of Merit projects doing very well indeed...
Nobody. That doesn't even seem to be the intent; it's not so much something to be adopted on its own merit as it is a passive-aggressive critique of real codes of conduct. Note how it repeatedly addresses what one may not do to address any kind of conflict or bad behavior, but it doesn't spell out any mechanisms to enforce even its own rules. Contrary to another commenter who says this can and should exist alongside a code of conduct, I interpret this as (intentionally) undermining any such companion.
It's just a not-so-clever way to imply that people who believe in codes of conduct don't believe in meritocracy (paragraph 4), lack technical prowess (para 6), seek disruption and deviation (paras 7 and 14) - all without actually having the guts to come out and say so. Thus it falls afoul of its own injunction to "discuss or debate the idea" (paragraph 9) because it doesn't even mention - let alone address - the arguments in favor of what it seeks to destroy.
But it happens!
There are people rage-quitting stackoverflow/stackexchange communities expressly because of they can't abide with the new initiatives/CoC that say one has to be nice and get along with others.
I guess this is yet another manifestation of that impulse. Maybe someday someone will write up a psychological analysis of this kind of behavior. I sure don't understand it.
I would like to read that; both what's driving the thinking behind adoption, and the responses.
You could apply it to any organisation that requires you to sign up to its rules before joining.
> It seems insane to me that someone would profoundly object to guidelines that effectively say "don't be an asshole".
Does this help? https://news.ycombinator.com/item?id=18075200
Offered as a possible explanation without taking a side: it is because the author of the CoC is perceived as asserting their moral superiority over the others, and the others don’t recognise that person as having earned the right to do so, such as by being a long-standing member of the community with an exemplary track record themselves. The actual content of the CoC isn’t the issue.
In the specific case of SO, it’s probably that certain behaviours were actively encouraged by the owners of the site via points and badges, then suddenly they changed their minds. People feel stabbed in the back.
I haven’t ragequit anything, this is all just a theory, not direct experience
Or to put it more succinctly: People see a bait and switch. The superficial language doesn't really seem all that objectionable, but if you look into the ideology behind it, you might find they have a very specific idea of what "don't be an asshole" means that maybe doesn't quite match what you'd expect.
Who the hell chooses a project to contribute to based on its "code of conduct" (the notion which didn't even exist for much of history of open source)? I thought people write code to solve actual technical problems, not just to flame each other on the Internet.
This sounds good, but a clause like this can easily backfire. What happens if a high ranking member is (whether they know it or not) a bigot or sexist? Anytime someone tries to challenge them calling out their behavior, they're likely to point to this Code and say "stop making this about gender/race as that violates the code of merit". They can use the very rules meant to stop them as a weapon to silence those who would criticize.
The document presumes good intentions by all those participating. Good intentions don't work- mechanisms do. I see no mechanisms here.
Where is this happening? The CoM says it can't happen on the project mailing list, or the project forum, or the project issues page ... Doing it on Twitter? Not within the project and fair game.
Also, why is "fair game" a concept that applies to whether misbehavior can be challenged and not to the misbehavior itself? If the contributor tweets, "Ew, all these incompetent purples keep making trash PRs," why should that itself not be considered outside the bounds of "fair game"?
but to get to your point: on a merit based system every reason to decline a contribution should be based on the contribution, not on the contributer. everyone should be able to validate those reasons. if you got a sexist and he declines your contribution with a sexist reason that should lead to consequences for him. thats what your quoted line entails. the high ranking member violated it because he took your sex/gender into account when considiering your contribution. did he decline with racist remarks? he violated it again because he took your race into account. for me that would be a far better system because it does not put the control in the hands of the few maintainers, it puts the control in the hands of the whole community.
Then we can avoid having an HR department for every open source project.
These are different goals, and the former is sufficient if you don't necessarily want a community (e.g. it's a corporate code drop) or you see some reason why people will produce patches regardless. But it's the wrong priority for major open-source projects created by decentralized, often volunteer teams. Those projects need active bug reporting, design review, thinking about future goals, feedback on existing designs, shared visions, etc. A process that simply lets you accept correct patches, should they somehow show up, won't get you there.
This is the process that Rust core team member Aaron Turon calls "pluralism and positive-sum thinking" https://aturon.github.io/2018/06/02/listening-part-2/ , and former Linux kernel contributor Valerie Aurora calls, interestingly, "feminist" https://blog.valerieaurora.org/2014/10/03/operating-systems-... . But whatever you call it, it's very different from a process that just answers "is this patch being reviewed with sound reasoning." Such a process would have soundly rejected v1 of the patches implementing all the things requested in those articles and likely discouraged contributors (again, for sound reasons, not out of bigotry), and not produced technically better and more meritorious work.
It certainly does not sound to me like this Code of Merit is specifically for supporting sexism like you imply here. It is just specifically against the Idea that Merit or Meritocracy is "dead" which is a common view of those pushing for the usual Code of Conduct stuff.
>This establishes that nothing outside of the project has an impact on the project itself. 1. Clause 11 does. Let's abstract the example of the social pariah you gave, since as you pointed out, Godwin's already got your number. Let's say we were talking about the sub-human degenerates, the utter voids of moral thought and character, the unforgivable scum, that are pro-skub. Now, while I hate them as much as any upstanding conscientious person does, I have to grant that this code of merit does not give them a remit to advance their hideous philosophy through the use of the software (as long as the society they are in is civilized enough to ban all of the actions we hate these people for).
2. It is not a given that a private or open-source software project has the social duty to ferret out secret pro-skubists. If I, for example, were to allow my neighbors the use of my lawn for social events, am I responsible for validating that none of the, in their heart of hearts, secretly desires the spread of that plague upon our species? Should I conduct a personality test on a fellow before holding the door for him, to ensure that I never help one of these vile cretins?
3. Even if this "person" is known to be pro-skub, are we obligated to refuse them any access to our community? If one of them, like the proverbial monkey at the typewriter, can cease his endless spewing of nauseating ideology to write valid helpful code, am I under a moral obligation to refuse it? If so, why? As long as they keep their disgusting opinions out of the professional space in which said code is offered and judged, I can isolate them in my mind as a code fountain and think nothing more of them. And if they do so dare to proselytize their villainy, this code of merit gives us the authority to remove the post-haste.
4. On a strategic anti-skub level, I disagree that total shunning accomplishes a useful objective. Ideally, we want the to understand that they are wrong people with bad opinions. Refusing any interaction with them will not accomplish this, as they will simply be led into more extreme pro-skub echo chambers that reinforce this twisted, amoral world view. How will they ever be led to the righteous path, if every guide shuts the door in their faces?
There's no need to draw the line. As long as Hitler writes good code and behaves well on project's mailing lists, issue trackers etc., I would have no problem with him being a project member.
Why should we prevent someone from contributing something good, thus hurting ourselves in the process, because they otherwise do something bad?
Rejects must be justified.
Pedophilia is not criminal (in "civilized" countries), it's just a sexual orientation. What you might be thinking of is child abuse. Please don't confound those two, because being a pedophile is neither a choice nor does it make you a child abuser, nor is all child abuse done by pedophiles.
edit: lol, downvotes for this? Really? I'd really be curious how those downvotes correlate with support for CoCs.
There is nothing morally wrong with Hitler contributing code to a project, provided there's nothing morally wrong with the impact that code has.
Most of the argument around CoCs is along the lines of "Hitler wants to exterminate people like me, therefore I don't feel safe being associated with this community, therefore Hitler should be excluded to make the community more inclusive."
Maybe the answer is that there should be less "community" around a project, and the work should speak for itself.
(I wonder how quickly someone will misinterpret my words as a defence of bigotry or National Socialism…)
It doesn't help to shun people just because you don't like them or what they do instead of helping them, persuading them, and encouraging them to grow.
If Hitler wanted to join my code project, I'd try to help steer him in the right direction and teach him to contribute something worthwhile.
I imagine you would have no worries about what might happen if Hitler's PRs are rejected and he gets angry about that?
That escalated pretty quickly.
This type of code will be chosen by the kind of people that were angry about the linux CoC. So sadly even though this document has nothing obviously wrong with it, it will be a huge red flag on a project.
It is something, but it is clearly not about inclusion or anything. Not that harassment was ever a significant problem in any repository or mailing list I visited.
I think a general request for being polite is always a good thing. Mandatory behavior expectations are not. And this CoC reeks like it.
Sure, though note that this description could just as easily apply to "Black Lives Matter".
I beg to differ. It's innocuous only at the most superficial level. Even a moment's reflection on how it focuses on what one may not do to address any kind of conflict, without providing alternatives, makes it pretty darn clear that this is not intended as an honest complement or critique of codes of conduct. It's more an instrument of sabotage, and that's pretty objectionable.
The alternative is probably the "tyranny of the outside majority". You can't do things _other_ people, unrelated to your work, don't like.
https://en.wikipedia.org/wiki/The_Rise_of_the_Meritocracy
> "It is good sense to appoint individual people to jobs on their merit. It is the opposite when those who are judged to have merit of a particular kind harden into a new social class without room in it for others."
Here are the two key criteria from the Code of Merit governing how contributors are rewarded:
> 4. Authority or position in the project will be proportional to the accrued contribution. Seniority must be earned.
> 5. Software is evolutive: the better implementations must supersede lesser implementations. Technical advantage is the primary evaluation metric.
However, these are inherently subjective measures, dependent on who is among the project's "managing members" and thus in a position to propose candidates and render judgement. At the very least it is an unstable system in the absence of formal governance mechanisms (e.g. 2/3 majority rule on proposed candidates) and committed leadership.
Ultimately, it is frighteningly difficult to avoid calcifying into an exclusive group, fulfilling the satirical prophesies of "meritocracy".
It is difficult for _any_ group to not calcify into a leadership position, but I'd rather have the calcified remnants of those who produced something at some time, instead of having an arbitrary committee based on modern liberal ideals and pushed by an external group.
So, the meritocratic option is to adopt the Contributor Covenant and the incident-handling practices it comes with, which empirically help produce great projects. The only reason to adopt the Code of Merit is ideological attraction to its worldview outweighing the desire for a better technical project.
