The rules lawyer in me sees these two points, which
can be employed to immediately shut up anybody for fear
of expulsion:
* Harassment (either in public or private; if someone asks you to stop
speaking to/at them, you must stop immediately)
* If someone takes issue with something you said or did, resist the urge to
be defensive. Just stop doing what it was they complained about and
apologize.
As soon as anybody talks to you, just tell them you "take issue with it" and they have to shut up or be shunned.
Also, this is is clearly US-centric, with its puritan-christian view of sexuality as destructive:
This section states the values to which Go enthusiasts (“Gophers”) should
aspire, and the kinds of behaviors that are not acceptable in our community.
...
* Romantic or sexual commentary, remarks, or questions.
Actually, the Code of Conduct is intended to be all-encompassing:
Where does it apply?
The Code of Conduct applies generally. If you
participate in or contribute to the Go ecosystem
in any way, you should
observe the Code of Conduct.
So, golang is a way of life, according to this CoC.
What I meant by off topic is that any "Romantic or sexual commentary, remarks, or questions" in a Golang communication forum are off topic.
Having that go against the code of conduct does not necessarily suggest a puritan view of the world, but an understanding that those are rarely constructive to the conversation.
As far as the sexuality bit, it's basic professionalism. The entire Code of Conduct would be much better if it was just "Be professional". Yes, there'd be many more judgement calls involved, but that's a much better plan than foisting responsibility for making judgement calls onto these kinds of rules.
>As soon as anybody talks to you, just tell them you "take issue with it" and they have to shut up or be shunned.
The rules lawyer in me wants to prove a point by harassing people through deliberately taking issue with what a particular person says. It'd be coordinated, and best if it was ironically directed at the people who wanted to bring in the CoC.
"Please do not publicly discuss this" is very worrying from a process standpoint. There's a very important thing that directly messaging the authors doesn't do - it makes people aware that other people find it unreasonable.
For instance, it'd be somewhat straightforward to imply that there aren't many people with issues with the CoC.
Yes. There's been a troublesome pattern lately where someone, usually a stranger, comes into a software-related community requesting a code of conduct, which usually enshrines a very narrow political viewpoint and is easily abused for harassment purposes; the community protests or at the very least demonstrates that opinions are highly divided on the topic; and then the operators of the community install the code anyway.
It kind of looks like in this case the operators of the community are going to cut out the middleman.
> For a community of this scale to survive and prosper, it needs guidelines to encourage productive and positive experiences, and to effectively deal with negative experiences.
Nope - actually it doesn't need any guidelines for its experiences because it is software, not an ideology. You can block spam and moderate discussions in whatever forums and mailing lists you own, but to associate a programming language with your arbitrary set of social norms is absurd. If anything, it is exclusionary toward people who don't subscribe to the "your freedom of speech ends where my feelings begin" world-view.
> While a major goal of this proposal is to make the community more inclusive, this does by definition exclude people that cannot abide by the goals and principles of the code. I see this as a regrettable but necessary and inescapable design tradeoff. The implementation of the code may cause us to lose a few people, but we stand to gain much more.
You "stand to gain much more"? Who are you to decide that creating rules to exclude one group of people in order to comfort another group is a good decision? And it's not an "inescapable design tradeoff" - you can escape the design tradeoff by simply not adding your rules to the project.
> Examples of "microaggressions":
> - J is a regular poster to the golang-nuts mailing list. On one thread, they make the comment "Go's type system is so simple even my grandma could understand it."
> - Another poster points out that the comment goes against the code of conduct, since it marginalises women and the elderly by implying that something need be simple for an old woman to understand it.
The phrase "even my grandma could..." is a fairly common idiom and is not meant to be taken literally. If anything, J's comment should be ignored because J is just stating a random opinion. However, playing the devil's advocate, I could say that the 2nd poster is actually committing a cultural "microaggression" against J, and is marginalizing J for J's distinctive dialect.
This is going to end badly. It's going to grow and eventually be used to stifle dissenting comments and open discussion.
The authors asking you not to discuss this publically is very telling.
So is this a current problem that even needs to be solved?
Rarely have I seen a programming language community turning so vile that wide reaching rules need to be established.
I agree with the concern voiced here that it could be (ab)used to stifle unwelcome discussion, even if the points all look nice and all at first sight. The problem with these is that they are so, so very subjective. When was something even "snarky", when does something "derail" a discussion, and perhaps toughest of all, how do you properly identify "microaggressions, subconcious actions that marginalize oppressed people", judging intents per definition not even conciously made!
Again, is this even a problem that needs to be solved, or is discussion thriving today? This should be the number one question. Number two: Which, if any, problems need rules today? No more than necessary, no less.
J and S are emailing back and forth on a golang-nuts thread.
D enters the conversation and proposes an alternative solution.
J and S ignore D and continue their discussion.
D re-articulates their point in a different way.
J responds to D by asking them to "butt out".
S emails J privately, noting that J's reaction was uncalled-for, and suggests that J apologize to D.
J replies that they have nothing to apologize for.
S reports the incident to the CoC Working Group.
T, a member of the working group, contacts J and S separately to get details on the incident.
T asks J to apologize for being unwelcoming and exclusive, and notifies S that this action was taken.
J acknowledges their mistake and apologizes to D.
The issue is resolved.
And here we see how a programming community turns into a daily asinine tumbler drama. This is why I don't take part in these bullshit "communities".
11 comments
[ 2.2 ms ] story [ 22.5 ms ] threadAlso, this is is clearly US-centric, with its puritan-christian view of sexuality as destructive:
...Having that go against the code of conduct does not necessarily suggest a puritan view of the world, but an understanding that those are rarely constructive to the conversation.
>As soon as anybody talks to you, just tell them you "take issue with it" and they have to shut up or be shunned.
The rules lawyer in me wants to prove a point by harassing people through deliberately taking issue with what a particular person says. It'd be coordinated, and best if it was ironically directed at the people who wanted to bring in the CoC.
For instance, it'd be somewhat straightforward to imply that there aren't many people with issues with the CoC.
It kind of looks like in this case the operators of the community are going to cut out the middleman.
Nope - actually it doesn't need any guidelines for its experiences because it is software, not an ideology. You can block spam and moderate discussions in whatever forums and mailing lists you own, but to associate a programming language with your arbitrary set of social norms is absurd. If anything, it is exclusionary toward people who don't subscribe to the "your freedom of speech ends where my feelings begin" world-view.
> While a major goal of this proposal is to make the community more inclusive, this does by definition exclude people that cannot abide by the goals and principles of the code. I see this as a regrettable but necessary and inescapable design tradeoff. The implementation of the code may cause us to lose a few people, but we stand to gain much more.
You "stand to gain much more"? Who are you to decide that creating rules to exclude one group of people in order to comfort another group is a good decision? And it's not an "inescapable design tradeoff" - you can escape the design tradeoff by simply not adding your rules to the project.
> Examples of "microaggressions":
> - J is a regular poster to the golang-nuts mailing list. On one thread, they make the comment "Go's type system is so simple even my grandma could understand it."
> - Another poster points out that the comment goes against the code of conduct, since it marginalises women and the elderly by implying that something need be simple for an old woman to understand it.
The phrase "even my grandma could..." is a fairly common idiom and is not meant to be taken literally. If anything, J's comment should be ignored because J is just stating a random opinion. However, playing the devil's advocate, I could say that the 2nd poster is actually committing a cultural "microaggression" against J, and is marginalizing J for J's distinctive dialect.
Rarely have I seen a programming language community turning so vile that wide reaching rules need to be established.
I agree with the concern voiced here that it could be (ab)used to stifle unwelcome discussion, even if the points all look nice and all at first sight. The problem with these is that they are so, so very subjective. When was something even "snarky", when does something "derail" a discussion, and perhaps toughest of all, how do you properly identify "microaggressions, subconcious actions that marginalize oppressed people", judging intents per definition not even conciously made!
Again, is this even a problem that needs to be solved, or is discussion thriving today? This should be the number one question. Number two: Which, if any, problems need rules today? No more than necessary, no less.