FreeBSD and Its Code of Conduct Anniversary (slashdot.org) 91
Tokolosh writes: On February 13, 2018 the FreeBSD Foundation posted its Code of Conduct. This included a system for reporting offenders, plus a Code of Conduct Committee to review charges and issue sanctions. The resulting story on Slashdot on February 17 triggered 859 comments. Needless to say, it was controversial.
In 2020, a survey indicated that some 35% of the FreeBSD developer community was dissatisfied with their 2018 Code of Conduct, 34% were neutral, and only 30% satisfied. So they set out to adopt a new CoC. A second survey asked which code of conduct should FreeBSD adopt? 4% favored keeping the 2018 code of conduct, 33% favored the Go-derived code of conduct, 63% favored the LLVM-derived code of conduct. The LLVM Project code was thus adopted.
My pragmatic question back in 2018 was, will this CoC lead to a better FreeBSD, more engagement, a larger, more productive community, and more market share for FreeBSD? In other words, does the CoC give FreeBSD an evolutionary advantage? If a different or no CoC had been imposed, would the FreeBSD of today be different? If so, in what way? The answer is not clear, so I am submitting this story to gather input.
In 2020, a survey indicated that some 35% of the FreeBSD developer community was dissatisfied with their 2018 Code of Conduct, 34% were neutral, and only 30% satisfied. So they set out to adopt a new CoC. A second survey asked which code of conduct should FreeBSD adopt? 4% favored keeping the 2018 code of conduct, 33% favored the Go-derived code of conduct, 63% favored the LLVM-derived code of conduct. The LLVM Project code was thus adopted.
My pragmatic question back in 2018 was, will this CoC lead to a better FreeBSD, more engagement, a larger, more productive community, and more market share for FreeBSD? In other words, does the CoC give FreeBSD an evolutionary advantage? If a different or no CoC had been imposed, would the FreeBSD of today be different? If so, in what way? The answer is not clear, so I am submitting this story to gather input.
Re: (Score:3, Funny)
^-- ??
I think you'd usually measure your CoC with a tape measure or ruler.
Re: (Score:1)
The problem is, the methodology of the measurement.
Just whip it out and drop it on your keyboard:
8====D
QWERTY
Can anyone beat that?
Re: How would you even measure that? (Score:1)
Re: (Score:2)
QWERTYUIOP[]\ and over the edge of the keyboard.
Of course I measured using one of those handheld keyboard you use for a media center.
Re: (Score:2)
knee jerk reactions (Score:3, Insightful)
don't worry, these comments will be flooded by knee jerk reactions to the "CoC" term alone, and flood with flamebait bullshit, because this is slashdot... and I can most certainly tell you these same people don't use, nor contribute, before or after the CoCs, to the FreeBSD community or ecosystem. They'll just be external voices.
From within though, the community has been expanding, epically in the past 12 months, but few of those reasons are BECAUSE of the CoC. It is just a tertiary "nice to have". But the pandemic has allotted more free time to develop FreeBSD resources, and the recent CentOS bullshit has helped push people to look at alternatives such as FreeBSD. This is where the uptick in this community is coming from as of late.
Re:knee jerk reactions (Score:5, Insightful)
From within though, the community has been expanding, epically in the past 12 months, but few of those reasons are BECAUSE of the CoC. It is just a tertiary "nice to have".
What are the numbers of this expansion?
Anyhow, I suspect that meny people here with that knee-jerk reaction might not have even read the Code of Conduct. So let's put it out there - CoC rules in italics, my comments in normal. From the CoC site:
The FreeBSD community has always worked to be a welcoming and respectful community, and we want to ensure that doesn’t change as we grow and evolve. To that end, we have a few ground rules that we ask people to adhere to:
be friendly and patient,
be welcoming,
be considerate,
be respectful,
be careful in the words that you choose and be kind to others,
when we disagree, try to understand why.
Well right off the bat, if the first sentence is correct, there'd be no need for a CoC travelling on now.
be friendly and patient,
I wonder what the definition of being friendly and welcoming is, because that's pretty vague? I'm pretty terse in person, and in a work environment, do indeed tend to the monosyllabics. I might flunk out before we even start - depending on the sensitivity of the person. And yes, I have had people complain about me at first - not everyone makes a good first impression.
be welcoming,
We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion or lack thereof, and mental and physical ability.
Of course, although my mental state might be a disqualification, and I would find it difficult to be friendly and welcoming to say, a Mike Lindell type. But yeah, that mostly works
Be considerate, Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
Once again, it's fine and I agree
Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the FreeBSD community should be respectful when dealing with other members as well as with people outside the FreeBSD community.
Of course.
Be careful in the words that you choose and be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable. This includes, but is not limited to:
Violent threats or language directed against another person.
Discriminatory jokes and language.
Posting sexually explicit or violent material.
Posting (or threatening to post) other people’s personally identifying information ("doxing").
Personal insults, especially those using racist or sexist terms.
Unwelcome sexual attention.
Advocating for, or encouraging, any of the above behavior.
Now we are getting into a potential problem. I've been working directly with people for a long long time, and the Do not insult or put down other participants. is a mine field, because a not insignificant number of people consider any criticism of thei
Re:knee jerk reactions (Score:4, Insightful)
>Now we are getting into a potential problem. I've been working directly with people for a long long time, and the Do not insult or put down other participants. is a mine field, because a not insignificant number of people consider any criticism of their work as an insult or is demeaning them. The other parts of that are obviously good. But the first sentence is really bad.
The problem here is that people can't tell the difference between "I don't think that's a good idea" and "That idea is bad", the former being an opinion, and the latter being a statement of fact.
Like one of the reasons I wanted to stay the hell away from software development and GPL projects in the first place is because of this perverse mindset that if you're not GPL-cult quality, then you and your contributions are unwelcome. BSD/MIT/Apache license projects have their own pitfalls as well, but usually there is no question about if you can contribute to a project or not, if your contributions are unwelcome in the core project, just fork it and go build your own fork.
I'll use BSD and GPL projects as I see fit, but I'm unwilling to contribute changes back to GPL projects I use privately because they will just get rejected for some reason that has nothing to do with the code and everything to do with how the project has to be "pure" for some reason.
Re:knee jerk reactions (Score:5, Insightful)
>Now we are getting into a potential problem. I've been working directly with people for a long long time, and the Do not insult or put down other participants. is a mine field, because a not insignificant number of people consider any criticism of their work as an insult or is demeaning them. The other parts of that are obviously good. But the first sentence is really bad.
The problem here is that people can't tell the difference between "I don't think that's a good idea" and "That idea is bad", the former being an opinion, and the latter being a statement of fact.
Like one of the reasons I wanted to stay the hell away from software development and GPL projects in the first place is because of this perverse mindset that if you're not GPL-cult quality, then you and your contributions are unwelcome.
Yes - the issue of volunteerism. I've seen some zealots destroy entire communities. and in some strange areas. Not too far away from my locale, there were a lot of Amateur Radio licensees doing emergency communications. They put up with all the certifications they had to do, and would operate from home or club stations in the event of mostly weather disasters. There were getting to be a lot of real zealots getting involved. Then one day, the rule was made by the zealots that every one of these Hams were required to get a complete background check, and undergo regular drug testing.
The response was "Bullshit! I have to be treated like I'm a crminal on probation to operate my radio from my house?" The reply was "We must be sure that the community is acceptable to do this work, so that's just how it is."
The results? The emergency comms in the area fell completely apart, gone, only one person put up with the requirements, but you can't have emergency comms with one person. The kerfuffle carried over into the region's radio club, destroying it as well.
I dont do much programming for open source, but have done documentation, which is sorely needed. But given that I'm not a warm and fuzzy person, I'm considering that as a part of my past at this point. I don't need someone freaking out on me if I correct a typo. I don't want my acerbic personality to be the determinant of the quality of my documentation. Not for volunteer work.
I'll use BSD and GPL projects as I see fit, but I'm unwilling to contribute changes back to GPL projects I use privately because they will just get rejected for some reason that has nothing to do with the code and everything to do with how the project has to be "pure" for some reason.
As I've noted, I can be a bit of a pill. I'm not rude or condescending, but I'm terse, and need an environment where I can be forthright. It's weird, I can write a lot of paragraphs, but in person I'm mostly yes and no, and short pronouncements. That has stood me well in the real world. But if I must triple check what I utter to make certain that I don't offend people who consider the smallest bit of timid criticism as a personal insufferable attack on them, it is obvious to me that open source - even my documentation efforts for it, is better handled by others. The fact that I'm really good at that is not important today.
Re: (Score:2)
Re: (Score:2)
Very sad that the club fell apart instead of just expelling whatever twat decided to go on a power trip.
I'm a teetotaler, but anyone demanding a drug test from me is told to fuck right off.
-jcr
The club had been pretty much taken over by the emcomm people, so when they fought with each other and left, there weren't many of the Hams who do the hobby to learn about electronics. We tend to call the emcomm people whackers, because they are like wannabe first responders. When they take over a club, it's pretty much the death knell one way or another.
And you're an idiot (it's NOT personal) (Score:4, Insightful)
> The problem here is that people can't tell the difference between "I don't think that's a good idea" and "That idea is bad", the former being an opinion, and the latter being a statement of fact.
It seems to me that people have a hard time distinguishing between "I'm not sure that's the best idea" and "you're an idiot".
We all have blind spots. We all say and do dumb things occasionally. Sure, just because someone has a different viewpoint doesn't mean try are saying the idea is bad. AND if the idea is bad, if it's been tried before and shown not to work, that doesn't mean the person who mentioned the idea is stupid! It's not personal!
If I tell you that I already tried that and found it it fails miserably, I'm saying that I too thought it was a good idea - that's why I tried it. There's no sense in getting offended. We BOTH thought that was an idea worth trying. If I made the mistake earlier than you did, so I found out it was a mistake - that's not a personal attack. No need to fight back; the sensible response would be "interesting, how did it fail?"
When I first clicked to reply, I was thinking about people who take any comment about an idea they had as a personal attack. Then it occurred to me that here on Slashdot every day we see the same mistake being made on the other side. We frequently see a post like this:
--
You're an idiot. Foo didn't come out before Bar, you illiterate chimp.
--
We forget that because someone makes a statement that is incorrect (or their autocorrect fucks up the statement) that doesn't make the person an idiot. It simply makes the *statement* erroneous, that's all. We should remember that just because it's good to be civilized human beings, and because it allows us to have better discussions.
When we habitually act that way, karma has a way of reminding us brutally. I mentioned we all say something dumb from time to time. If we get in the habit of being an asshole, sooner or later we'll say something dumb WHILE being an asshole. Then we end up making a post like this:
--
You fucking moron. You know nothing about networking.
TCP packets go INSIDE of UDP packets.
Without UDP, you couldn't have TCP. Get clue, moron.
--
Then of course everyone else points out our error in the same tone we made it.
We can either choose a little bit of humility up front, or we end getting a lot of humiliation in the end.
Once or twice I've found out later that a particular person with whom we disagree on something is a top expert in their field. Calling them an idiot, illiterate, etc would have just made me look like a complete jackass. Once upon a time many years ago, I started writing a not-very-nice email to tell someone to stop posting off-topic shit on a technical discussion list. Just before hitting send, I saw that the guy's email address was vcerf@mci.com. I'm so glad I didn't send that email. I would have looked like a real jackass.
Re: (Score:3)
Funny example of what I was talking about:
https://www.reddit.com/r/donty... [reddit.com]
First guy is talking about the moon landing.
Second guy replies suggesting that the moon landing was faked. Tells first guy "if you don't think there's any sketchy stuff about the moon landing you need to do your research".
The first guy is Buzz Aldrin.
See also explaining Godwin's Law - to Mike Godwin.
https://www.reddit.com/r/donty... [reddit.com]
Re: (Score:3)
It seems to me that people have a hard time distinguishing between "I'm not sure that's the best idea" and "you're an idiot".
A lot of people have a hard time distinguishing between "my emotions tell me I'm right and you're wrong" and "I say you are wrong that's an objective FACT". Many programmers say the latter and mean the former.
Re: (Score:3)
The bit about programmers at the end for me thinking.
There is something else programmers do that it's good to be aware of. I did it yesterday.
Before going into the other thint, of course a lot of people do that. Sometimes they do that, and to prove that they are right they will cite something, like this:
--
Person A: You have no idea what you're talking about. You should read this article [link] to get a clue.
Person B: I'm glad you liked my article. I think you misunderstood what I wrote in the article you
Geez I'm long-winded (Score:2)
I might have been rambling. Let's try the short version.
You: X is broken
Programmer: The log says Y is broken
It *sounds* like the programmer said "you're wrong and that's a fact". That's not what the programmer said. They didn't say anything about you and they didn't say anything about your statement. That only said Y is broken, which is a fact.
It might well be that Y is broken because X broke it.
With programmers, can forget to mention possibilities like that, instead stating only the facts we know.
Re: (Score:2)
The problem here is that people can't tell the difference between "I don't think that's a good idea" and "That idea is bad", the former being an opinion, and the latter being a statement of fact.
Both have their place. The difference is that the second from needs to come with at least reasonably conclusive evidence.
Re: (Score:2)
There should be another rule added to all CoCs:
No rule lawyering, we know what words mean and arguing over them is not constructive or helpful. If you have issues, please use examples to illustrate them.
Re: (Score:2)
There should be another rule added to all CoCs:
No rule lawyering, we know what words mean and arguing over them is not constructive or helpful. If you have issues, please use examples to illustrate them.
That would be nice, but people do that all the time. On this side of the pond, we call it wordsmithing.
Certainly, adding a personality requirement to FOSS community work is right up there, and ends up castigating people someone might just have a personality conflict with. I know - and work with some even now - people that get very upset if they sense any criticism at all. You end up walking on eggshells. Until you offload them.
The people who freak at any criticism and take it as a personal insult are
Re: (Score:2)
Some pointers on how to give constructive criticism would be helpful. A lot of people just jump in with "this is shit, you fucking moron", or worse some passive aggressive snark.
Re: (Score:2)
Some pointers on how to give constructive criticism would be helpful. A lot of people just jump in with "this is shit, you fucking moron", or worse some passive aggressive snark.
But that isn't what I'm talking about. That example is rude, and provokes a defensive reaction. The ones I'm talking about are when you say something like "There's a problem here", and you immediately see them bristle. Those people won't take telling, so the only thing that is remotely constructive is giving them a tiny project that isn't really important so they can figure out for themselves what they are doing wrong without dragging the rest of the group down. Just tell them "Great work!" and move on. The
Re: (Score:2)
I try to avoid leading with "there's a problem". Try instead to say something like "see how this does X, and then Y happens..." and lead them to the issue by understanding it. That way by the time they realize there is a problem they at least understand what it is.
Some people don't need that, some people it helps. Costs nothing, I'll probably have to explain it anyway.
Re: (Score:2)
I think you're trying to change people's personalities here by having them soften their ways and stance. The GP already said that he's considered terse, probably by most people's standards. I can relate to him, as I've been called both abrasive and terse by people complaining to higher ups about my interactions with them. I actually don't mind if the users think that. That just means that the next time they have an issue they'll think more about their issue before coming to me. That is until we've had
Re: (Score:2)
I try to avoid leading with "there's a problem". Try instead to say something like "see how this does X, and then Y happens..." and lead them to the issue by understanding it. That way by the time they realize there is a problem they at least understand what it is.
Some people don't need that, some people it helps. Costs nothing, I'll probably have to explain it anyway.
That's the walking on eggshells part that slows projects to a crawl.
It's the idea that I am wrong and bad, and the overly sensitive person is both good and right. I must coddle, and they can remain free to take insult at anything forever. That's my point. I am not evil, but by these rules, I am. There is nothing in the Rules that requires growth on anyone but me. If I must change, why can't they? Going through life unable to handle anything that might be called adversity or disagreement is not a good way
Re: (Score:2)
I find it greatly speeds up projects because people are more willing to bring problems up early, rather than trying to fix them on their own. The more constructive and open the atmosphere the better it goes.
Re: (Score:2)
" I've been working directly with people for a long long time, and the Do not insult or put down other participants. is a mine field, because a not insignificant number of people consider any criticism of their work as an insult or is demeaning them. "
^^^This^^^, x1,000
I've lost one job where a very influential manager floated a solution to a problem, which I didn't think would work. Suggested an alternate plan, and what I thought was the flaw with the other, but wasn't my decision to make - I really didn'
Re: (Score:2)
From the updated code: "It is important that we resolve disagreements and differing views constructively." Yeah, the issue is that not everyone is working towards optimal coding ... there are *some* people who put their reputation first and foremost.
It's that continuum effect - so many individuals. And different people have different reasons for getting involved. Some it's feathering their caps. Some it's giving back. Some, it's advancement of FOSS. Some enjoy causing drama. Some are willing to burn down the neighborhood. We have to decide what the overarching purpose is.
No knee jerk reaction, quite thoughtful... (Score:5, Insightful)
...these comments will be flooded by knee jerk reactions...
Negative. This is a very thoughtful assertion that BSD's code of conduct is so utterly unimportant as to be irrelevant. When a project's major discussion point is its code of conduct, perhaps its time to surface a few layers. I mean, a discussion about a code of conduct is like three layers deep into meta. It's a discussion about how to have a discussion about how to behave with those who write the code. I mean seriously, how about we all just get slightly thicker skin, and write some fucking code.
Re: (Score:2)
I mean seriously, how about we all just get slightly thicker skin, and write some fucking code.
That is a good suggestion overall. Many people would benefit from it. But this includes the people getting called out for their behavior. Grow some skin and take the criticism like a fucking adult. Don't throw a fit because other people don't like the way you are acting.
Re: (Score:2)
It certainly takes me back to see the 'no true FreeBSD user' line used to dismiss all criticism or questions concerning the CoC. It was very common back then, with true believers ap
Did it improve things? (Score:2, Funny)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2, Insightful)
We've literally had "Ask Slashdot" for well over a decade... and yet, every single goddamn time, someone posts a link to that wiki article. Apparently questions are no longer allowed to be asked.
Re: (Score:1)
and the person is a 5-digit uid!? did they buy the account or something???
Re: (Score:1)
and the person is a 5-digit uid!? did they buy the account or something???
some of us have actually been here since back then.
Re: (Score:2)
I guess he finds it amazing anybody would be stupid enough to hang around that long, given how idiotic the readership has become.
Re: (Score:2)
I remember those days...
Re: (Score:2)
Don't worry, my comment got modded down to zero. That's called being "decent" these days.
Re: (Score:2)
You're free to ask whatever you want. But stay in your lane if you are technically inept. Actions have consequences, right?
Re: (Score:2, Flamebait)
See the part where I added my own headline to my post, such that the response was to that headline?
Right. So many people were offended by the joke they modded it down.
You know, in the name of tolerance and decency!
Re: (Score:2)
I'm not the one demanding nobody insult me.
Insult away, I'll be fine.
Cmon, go for it. Bring your A game not this warmed over, passive aggressive, half hearted effort. You can do better.
What market? (Score:2)
Market share of what exactly? Just hacker desktops, or some sort of commercial use? Is there a financial value to make comparisons with? Or is this a question of contributions to FreeBSD development?
No (Score:5, Insightful)
To all questions.
People will not engage to a project because of its CoC. It helps them leave.
The most useful CoC: "Don't be an ass".
Re: (Score:2)
Above all, if you are an incompetent idiot, and have no business contributing code, STFU and just go away. Half of these CoC morons have zero technical ability, so they'd rather spend their time tilting at windmills than learning a useful skill.
Re: (Score:2)
I am far more likely to work on a project if it has a clear CoC. There are projects I have steered clear of because of poor community behaviour and standards, e.g. MAME. Their CoC is literally just "don't be an ass", but people are an ass all the time and it's become so toxic it's not worth even trying to engage with.
So instead I just keep my modifications private until I'm happy with them and then throw them out with no attempt to commit anything back. If they break other stuff... Well, I don't care, I'm n
I've never called an idiot an idiot publicly (Score:4, Interesting)
Re: (Score:2)
Consider this, if Linus called you a git then you know he respected you enough to read your submission.
What if he called me a github instead?
Re: (Score:2)
Re: (Score:3)
Calling someone an idiot is a shitty attitude to take. Human beings make mistakes, there's no need to be a dick about it.
The best engineering gets done when you have a no-blame working environment. Everyone gets on with solving problems, it doesn't matter whose fault it is, only that it gets sorted out and everyone learns from it. The process should ensure that such things don't become major problems, so if they do you know that the process needs improving.
Calling someone an idiot just makes them less likel
Re: (Score:2)
I've observed it does bring the people involved closer together.
Does it really bring people closer together, or were you observing people that were already close?
There is nothing wrong with jokingly calling your friends idiots, if that is the jargon you are using. I often do that myself. But all people involved obviously know it is not serious.
It's a whole other matter to do it in public forums, or with other people present. It is especially bad in written form where tone of voice is hard to convey, and where things get quoted out of context.
How droll (Score:3)
triggered 859 comments
Well played, BeauHD. Well played.
Re: (Score:2)
Do you want us to speculate? (Score:5, Insightful)
Well, give us something to work with. Commits/day before and after? Number of unique committers before and after? New committers after, and did any old consistent contributors seem to drop out after? Let's have the numbers!
Re: (Score:2)
In particular, cases reported and decided and what was decided?
Clearly No (Score:4, Insightful)
It seems quite clear that it wasn't successful. It was a highly controversial change that created a lot of drama and divided the community. Only for them to adopt a different CoC two years later when only 4% supported keeping it. If that's not an outright failure then what is?
As for whether having a CoC at all gives FreeBSD an advantage I'd say that's also a no. There has been big push for these CoCs over the last four or five years, but has any project seen a up tick in users or developers as a result? I haven't even seen any claim that they have. It's been long enough that we should have seen some kind of results. Yet the advocates for these CoCs are still pushing them on theory it will create more engagement rather than holding up examples. I'd say that is pretty telling in a community as results oriented and data driven as this one. It seems the only thing these CoCs do is create drama.
Re:Clearly No (Score:5, Insightful)
What they do is replace competent people with incompetent busybodies. It's the (self selecting) HOA effect. Only the people who can stomach being Karen are willing to "lead" in the new environment of being lead by morons. Everyone else who is actually can do useful work would rather spend their time doing ... useful work.
Re: (Score:2)
Indeed. Anybody focused on tech can always find a community that welcomes that and does not elevate secondary things to the status of "important".
Re: (Score:2)
A common complaint, but strangely all these highly competent real engineers never go on to just fork and do something useful themselves.
We had the same thing with systemd. Lots of complaints but the bottom line is no matter how much of an ass Poetering is nobody else has managed to come up with anything better.
I'm starting to suspect that these people are not quite as great as they think they are.
Re: (Score:2)
Nice theory. The reality is that hasn't happened.
Re: (Score:2)
Indeed. The only justification ever given for a CoC being beneficial is that it is "obvious". Nobody seems to be willing to give any actual numbers and I suspect that some are hiding numbers that show "slight" to "pretty bad" negative effects. Of course, adopting a bad CoC may also just be a general symptom of a project in decline, so even with real numbers it would be hard to tell.
What is absolutely certain is that nobody has significant _postive_ numbers. Because if they had, they would have blasted that
Neutral? (Score:2)
Aspirational vs. Minimal Standards (Score:2)
Things like "Codes of Conduct" and "Mission Statements" and "Codes of Ethics" are "aspirational" in nature, that is, ideals toward which we aspire, which we wish to attain more often than not, but don't expect to reach 100% of the time.
You have to fall all the way through the bottom before they become "rules" of any kind, with any kind of penalty.
Inherent in Codes of Conduct is the notion of "forgive and forget", where learning curves and change are tolerated, so long as progress is made.
When it all goes wr
Re: (Score:2)
Re: (Score:2)
So I can still say that boys are boys and girls are girls and that won't violate the CoC? Or renaming the Git back to "master" to avoid breaking the Git standards and decades worth of code?
Because if it's all just aspirational, then you shouldn't be offended when someone has a good, scientifically testable, reasonable viewpoint and make changes according. If you insist there must be changes, then it's a rule, not an aspiration.
There's always OpenBSD (Score:3)
I refuse to use any software produced under a CoC. Fortunately, I don't have to.
https://www.openbsd.org/ [openbsd.org]
My Perspective (Score:5, Informative)
I helped draft the 2018 CoC (but disliked how it was adopted). I helped get the replacement adopted (LLVM or golang, I didn't care: both were so much better). I'd like to share my personal views.
The takeaway is simple. The 2018 CoC was adopted w/o input from the community. It was poorly drafted and some of the worst examples were held up to ridicule. It also appeared when people were itching for a culture war fight, so a lot of outsiders dog-piled on it. Worse than that, though, was that it was also a poor document to help field complaints of bad behavior and help people interact in a more respectful way. It also had bad reporting mechanisms that encouraged abuse. It was a poor fit for the community that wants aspiration, not prescription. While it was a mistake to adopted what was effectively the rough draft of the drafting committee w/o the review we thought it would get (in general engineers suck at drafting high quality CoCs), it was an even bigger mistake to try to adopt it by fiat w/o a community discussion. So whoever said it can't be viewed as anything but a failure: you are right on that point...
The 2020 LLVM adoption is a much better fit. The reporting issues were also fixed. It provides better guidance on behavior that has been found to promote collaboration. It gives much better guidance for dealing with friction between community members. There have been fewer formal complaints, though it is still early. And the best thing: so far there haven't been the wide-ranging flame wars over its content we had with the last one. The project has been more focused on technical arguments and working to get FreeBSD 13.0 out the door.
The real takeaway here is that a bad CoC can drain the energy out of people. No doubt about that. A good CoC disappears into the woodwork. It's better to admit failure with a bad one and move on than to stubbornly enforce it at all costs. Also, engineers have a poor track record of drafting high quality CoCs: let others that have been successful do it and just use theirs was another take-a-way. Community engagement is also key, because that leads to community buy-in (a lesson learned from the 2018 experience). The CoC should reflect the community's values and aspirations. The more it does, the more buy-in you'll get which is key to it's success. I'm sure that in some years, the community's standards and values will have evolved enough to warrant revisiting things like this CoC, but for now it's at least a decent fit.
Lately, it seems to be working... The project has put its energy into adopting git (I know, a bit late), moving to asciidoc for its handbooks and docs, moving to OpenZFS as our ZFS upstream and getting the FreeBSD 13.0 release ready (due next month). It kinda surprised me to see this come up at all since things have been so quiet on the CoC front lately...
Anyway, I'm sure this won't please everybody. I'm sure some will disagree with me. But I think my perspective on the project's experience might be of interest.
Warner
Re:My Perspective (Score:5, Insightful)
The lack of consultation in FreeBSD was certainly a big issue. That the CoC was derived from Geek Feminism was also a red flag.
The lack of consultation was exacerbated by the combative responses to concerns. Those concerns were not surprising and would have been equally likely had the CoC been sourced from 'Geek Socialist', 'Geek Men's Rights', or 'Geek Catholicism' - with concepts and language of the respective ideology being apparent in the document. It was an overtly political source, an ideology that seemed to have no necessary place in the project. People raising concerns, as is typical where identity politics is introduced, were themselves accused of being politically motivated. It didn't matter if you were a user or a donor, your concerns were dismissed as racism or sexism. You either accept this or you're a terrible human being. Most of these political intrusions are made into spaces already pretty progressive. This is because these groups are less likely to simply tell them to fuck off, so identitarians go where believe they can make a new home.
One common criticism was that the supporters of the CoC could not provide evidence that their CoC was addressing an existing problem or an appreciable risk of the issue arising later. That's what made it clear that the only 'problem' being addressed was the lack of identity politics. That was when I quit donating and dropped FreeBSD. While there are traces of identity politics in the LLVM CoC, its origin is far less overt in its politics. Certainly, if there has to be a CoC in order to be in the latest tech fad, Speak Up! was less divisive than Geek Feminism. When they scrapped the CoC I returned to FreebSD, albeit with less enthusiasm than before.
It's not clear that these CoCs improve a project. They appear a solution in search of a problem, and arguably creating the problem they purport to tackle.They are similar to the claim that supposed diversity improves projects and businesses.
While differing perspectives can be helpful (e.g. experienced engineers alongside new and talented engineers, arts combined with the sciences), it's not at all clear that actively seeking a mix of arbitrary physical traits is broadly beneficial. It's particularly useless when hiring a Burger King Kid's club of races and genders, yet everybody has the same socio-cultural background. It's only superficial diversity. It's one of the aspects of corporate 'diversity' that annoys me the most. There is no diversity when everybody has the same background and same worldview. Even in seeking diversity, it has to be related to the product if it's to be of use. Creating a product for the Chinese market? Probably a good idea to get some people who have experience with China. Making a product for women? Definitely a good idea to have women in the team. Sticking a random Chinese or female person in a team, because 'diversity'? Less useful.
There's also the very well evidenced problem of social cohesion breaking down where disparate group identities become increasingly salient, and we've also long known that threat to the majority group identity doesn't end well. Hell, this is research going back to the 1950s that remains relevant today. The keys are to have a shared focus that creates a group that becomes more salient than other identities. Just because I'm a minority doesn't mean I need to have that celebrated or made relevant, so long as I can be accepted as part of the group. Identity politics, on which the CoC was based, elevates difference and creates the majority group threat that we know creates division.
Re: (Score:2)
Sounds like a well-observed and well described take-away message. Also matches what I expect from a CoC: Done well, it has little to no impact except maybe for some extreme cases, but not done well, it can have a large negative impact. There is also another message in there: Do not really regulate what works well and only regulate what does not if you cannot fix the actual root cause. But if you do, be aware that you have _not_ fixed said root cause. A CoC will certainly never fix any culture that is alread
Re: (Score:1)
I could say so much more. But in the interest of brevity, I'll keep this brief. Let me start by saying thank you for sharing your view. I wish I would find it more illuminating, but the whole CoC thing isn't very bright to start with.
The takeaway is simple. The 2018 CoC was adopted w/o input from the community.
Unkindly, this is an admission that it was the product of bureaucratic busybodies with nothing better to do than to prescribe behaviour, this time to humans.
It also appeared when people were itching for a culture war fight, so a lot of outsiders dog-piled on it.
Point of order: Having to have a CoC was also an external idea, pushed by a very peculiar set of people with a specific
Re: (Score:2)
A good CoC disappears into the woodwork.
And then you don't need it.. [snip] ...So now you believe you have a good one, which disappears into the woodwork. Thus it is a tickbox item that you felt you had to have because everyone else seemed to be having one of those. And the cost of ticking that box is three years of bickering. [x] Good show.
This perfectly sums up why all of this CoC stuff is utter nonsense: at the end of the day, the bulk of a CoC boils down to "we expect you to behave like a decent human being". Not only are they all essentially the same, they all state the obvious, and they try to codify things that can't be codified. The process of creating and adopting them takes tons of energy but fixes no real problems, and usually causes a lot of strife in the process.
Re: (Score:2)
Except both these points are wrong.
It's like the rules of the road. We don't have people crashing into each other because there's rules about when and where to drive. Nobody is suggesting because they have disappeared into the woodwork of society that they aren't important and play an important role.
There's also a bit of a logical fallacy in the 'one was bad, therefore all are bad'. And this last round, there was no strife: we learned the lesson of reuse and reused one that worked.
So you could draw the conc
Re: (Score:2)
That's a poor analogy, in part because most rules of the road can be spelled out objectively and with precision, while CoC rules are inherently wishy washy. With 2 or 3 rules we can define with a good degree of precision allowed behavior for a road intersection that uses a roundabout, but a list of a 100 rules wouldn't adequately describe how not to be a jerk.
As for 'one was bad, therefore all are bad' line of thinking: no, I didn't suggest that. But I've yet to see a CoC that solves any actual problems. Ev
Re: (Score:1)
So you think because we're used to the rules, the rules can be changed at will?
We don't have people crashing into each other exactly because the rules of the road exist and those rules are rather unchanging. We had rules before about not BEING a dick and the rules were changed to reflect ideas about not HAVING a dick.
Re: (Score:1)
It's like the rules of the road.
No, it's not, actually. The rules of the road are a set of, in some ways arbitrary, but specific things to do and not do that pertain to the road and the vehicles on it. The rules of the road are topical. The choices the rules make arise from and have direct connection with the act of using that road.
Codes of Conduct, by contrast, codify behaviours that pretend to be more universal though they are at least as much arbitrary, and do not connect to the topic of the group at all. Not in motivation to have th
Re: (Score:2)
The perf improvements I've seen with 13 have my very anxious for the release, thanks for the work you do!
Typically, this is counter-productive (Score:3)
If you have to formalize things like that, the project has stagnated and is not carried by enthusiasm anymore. There will also be people pushing in that are (on the tech-skill side) somewhere between below average and abysmally bad. Hence a CoC will never have any positive impact in a space where the primary goal is not the interaction itself. It can have anywhere between negligible and massively negative impact though.
However, I do not think the FreeBSD community _had_ to do this and the LLVM CoC seems to be pretty harmless. Hence the effect will likely be negligible and only minimally negative.
That said, in a community where interaction _is_ the primary goal, a CoC may or may not be a good idea, but at least there it is directly tied to what people primarily gathered to do together.
I though the whole point of CoC was to exclude (Score:1)
people.
It's in a death spiral and playing body politik isn't going to get anyone writing code, at best it'll get you more commissars, and speech police. Until they start abducting people to force them to do stuff to fulfil the paradise of representative outcome, it's just not going to happen.
Why do we even let girls choose NOT to go into science? What is up with this free will shit?
This is also the anniversary of (Score:1)
Re: (Score:1)
Yep, the same thing here. The progress on FreeBSD was going well, it stopped pretty much after the CoC, all qualified contributors quit and we still don't have any more AMD support or 40/100GbE network cards in FreeBSD which was actively being worked on until that point. The community is not just about the big developers with big names making big changes. Sure it's important, but what keeps the project alive is the hundreds if not thousands of contributors for small niche applications.
However the people beh
Censors always lie about motives (Score:2)
When they say they are censoring "hate speech" or "misinformation" that always mean they are censoring any opinion that does fit their narrative. Always, every time , no exceptions ever.