I see that having CoC is getting standard with OSS projects, old and new alike. But have no idea if it actually does anything.
Codes of conduct are more about changing who is in the community than about changing the conduct of existing community members. Periodically someone runs afoul of the ruling elite who pass judgement upon them behind closed doors, usually leading to excommunication. The atmosphere of knowing what you say will be reported upwards and optionally stripped of context and rephrased to your detriment promotes an environment of inclusivity and safety.
I'm not totally clear what "inclusivity" means at this point. It seems to be "excluding unpopular people and ideas", which should be termed "exclusivity". I've been known to say openly critical things about parts of our industry in public - basically because a lot of software dev is done really badly - and that sort of general negativity has no place relative to enthusiastically praising whatever nonsense is going on at the time.
E.g. you go to a talk on concurrency. You know it's nonsense, the code on the slides was wrong and the speaker has totally misunderstood the domain. So you talk with fellow attendees about how it was really interesting and excellent. One guy says "the first example deadlocks", and that makes someone feel uncomfortable, properly fixed by kicking him out of the conference. This is very inclusive and good for industry. Then you all go off to write code that doesn't work.
edit: can't believe I forgot the best part. If there's someone in the community you don't like - maybe their work makes you feel inferior, or they're a competitor in some sense, the burden of proof for triggering evisceration by committee is usually negligible. Tell some people they made you feel uncomfortable, let some of them talk you into reporting it and put them down as witnesses, bang - problem solved. Very convenient.
Most of the developed world has really clear ideas about the scary things - sexual assault, harassment and so forth, dealt with by a judicial system. So the honourable goals of the CoC systems could be achieved by following norms of society with the existing structures in place. That seems better to me.
Oh, please. That's just unfounded FUD-spreading.
DI became DEI became DEIB in less than a decade. They are working on new initials as we speak, to confuse and demoralize anyone who opposes this make-it-up-as-we-go-along sophistry. Inventing all of this language infrastructure around what used to just be the Golden Rule is clear nonsense.
E - Equity (not equality)
I - Inclusion
B - Belonging
Inclusion
Equity
Belonging
they're not meaningful
uh, i might be out of the loop, what's wrong with the word "deadlock" now ?
The CoC people are relatively transparent that they want to be able to push people like Torvalds and Stallman out of projects. Raising the question; do we have a limitless supply of Stallmans and Torvalds out there to draw on, or are these people actually quite rare? From what I can tell they are quite rare and need to be encouraged in the good they do rather than ostracised for the flaws that all humans have in some way or another.
Stallman is a great example. There is a long queue of people lining up to criticise him, but nobody has successfully cobbled together an alternative to the FSF. It wouldn't be hard. GPL 2.0 hit a better sweet spot than 3.0. Nobody has stepped up to the plate.
This isn't true. I have actually seen several non-FSF/OSI attempts at licenses in the recent past, most notably License Zero with its Prosperity and Parity licenses, as well as alternative licenses like the Server Side Public License and Business Source License.
The trouble is that attempting to learn from the lessons of past licenses tends to draw a lot of dogmatic outrage because said licenses either don't conform to the open source definition or four freedoms - or at least, not in the opinion of the OSI or FSF.
If developers are unwilling to think outside those boxes en masse, then we are in effect "stuck" with the existing power structures. And that power structure is what led to things like the wide preference of permissive licenses and promoting and prioritizing the GPLv3 over the AGPLv3.
They generate outrage because they are accompanied by people trying to change the definition of open-source, not with the idea of alternative licenses.
If the precondition of learning lessons from past licenses is that they must follow the rules set by those past licenses as holy writ, then it follows that organizations like the FSF with leaders like RMS are the best you can hope for.
Personally, I think we as a community of developers are capable of better.
- Shared Source
- Clear Source
- Awesome Source
- Friendly Source
- Just SourceOpen source means things and people are right to complain when your license doesn't mean that. So you can have your Source-available licenses, use them if it's right for your project, but stop trying to freeboot off the OS/FS brand.
Probably why M$ owned github encourages them.
Is there a current need for the FSF or alternatives? There's a wide variety of licenses already developed and between GPL2 and 3, LGPLs, AGPL, BSD/MIT, Apache, Mozilla, and normal commercial licenses, plus or minus PATENTS files, I'm not sure we need an organization that is developing another license, plus advocacy, plus developing a collection of fairly unrelated software at this point. I guess you could say the Apache foundation almost does the same thing, although I don't think they did much advocacy to use their license.
Yes, FSF was important, but when it winds down, it will not be replaced by one organization.
The issue I have is the people who are confident that cancelling that person is a good idea. It seems like a mistake.
careful there you will get some very bad takes, and memes on Popper's paradox of tolerance, which has been completely bastardized to justify all manner of intolerance these days...
I think this line of thought deserves some exploration.
If the burden of proof truly was negligible, CoCs would probably be weaponized more often. My impression is more that the burden of proof is reduced selectively, in favor of people who are good at a certain type of politics / playing social games.
So CoCs can be perceived as a shift of power away from technical merit and towards social skills. No wonder there's a backlash from a lot of technical folks. It's also objectively questionable whether such a shift of power is useful for projects.
(Humans are always gonna politic, even if it's only nerds, but the normative shift of whether politicking is officially condoned or even valued is what matters)
I don't think it's a surprise that we're seeing CoCs in this age of commercialized open source. In the 90s and 00s, open source projects could only survive by technical merit. Nowadays, corporate sponsorship is a very important factor in project viability, and with corporations comes the bigger focus on politics.
Towards social merit. If you can't/won't convince the new "powers that be" that you are sufficiently aligned with their dogma, then goodbye.
"If you have a CoC, then you have formal rules around moderation with the option to appeal"
Basically, when someone does something stupid (and let's be realistic, it will happen) then there are clear rules and processes to follow.
It seems a lot of people have a problem with the wording, or the implication that their behaviour may be bad and get them removed.
conferences became cesspits.
project leaders went from knowledgable dictators to well-liked community leaders, who had no idea what they were doing, and into which direction to go forward. the yes-sayers.
I am certainly aware of projects which have banned people for CoC violations. These usually aren’t loudly publicized, so I’m not going to do so here. Would those projects have banned those people anyway? No way to know.
- Regular meetings to keep everyone on-track (as nobody is being paid, its a passion project, etc)
- Setting up clear rules and moderation guidelines, together. The team sat together and came up with a list of do's and don't's, best practices and principles to be used when moderating. Such simple ideas as "maximizing interaction" while keeping within the rules and Discord ToS, had a noticable impact. This was also useful to review moderation action that had been taken, and evaluate moderators, and possibly rollback moderation actions that were not in line with the code of conduct.
TL;DR: Formalizing rules that have existed informally only makes it easier to review moderation actions, to moderate, and to add new people to the team. It also clarifies to the community how moderation is done.
There's a difference for baning people in places where they should behave professionally, and banning people for stuff they do outside of those places.
For example: is hurling abuse at another member about their sexuality in a bar not connected to a conference, "a space under GCC control"?
Technically: no. But those people are only proximal due to participation in the project.
But maybe they don't do it to members. Maybe it's just their hobby - attend GCC conferences and hurl abuse at people in the nearby gay bars each night, then show up the next day in the T-shirt and conference badge, forcing the reception staff they were yelling at the previous night to interact with them.
Again: technically, not connected to GCC. After all - they could fly to any city they want at any time and do this. They're not doing it in "spaces under GCC control". But they're doing it right next to them. And any member of the public making casual observations would start to see the pattern of this happening whenever a GCC conference is in town.
With other environments like forums, or even single commits or issues opened, I think it shouldn't apply; they're just randos, often even anonymous.
But with some projects, where for legal reasons people's real names & identities have to be exposed, it becomes another matter.
For what it's worth, I dislike real identities on the internet; I think e.g. open source projects should allow contributions from randoms / nicknames. But I guess there's legal issues.
Ideally a community should not need this. But most so-called communities are not communities. Membership and participation can be fleeting so there will be a constant influx and loss of members and participants, all of whom hold different values and some of whom the original founders would have never invited in the first place.
So the risk is that a project built by people sharing a common set of values may be recuperated by people diametrically opposed to those values. Defining those values helps with that. For the primary demographic of HN, usually "don't be a dick" suffices for this. The problem is that lists of values don't provide an enforcement mechanism.
This means you likely end up with one of two situations after a preexisting project adopts a CoC: either nothing changes because the code of conduct is not enforced (or only inconsistently), or nothing changes because everybody already involved in the project agrees with it and those e.g. throwing slurs at existing members or otherwise harrassing them would have been kicked out anyway.
The problem is when projects that don't have a strong ideological/emotional investment in codifying a set of shared values (or lack a consistently shared set of values altogether) treat a CoC like a DEI program and just bolt it onto their project to tick a box and stop people from complaining. This misleads those who treat CoCs seriously into joining while also weakening the signalling effect of CoCs for other projects. In my experience this is the case for most OSS projects and in the worst cases it leads to overeager admins enforcing the letter of the law because there really was no spirit of the law to begin with, going through the authoritarian motions of enforcement without any ulterior purpose - and of course these projects will still selectively spare particularly influential individuals regardless of their misdeeds.