Matz: I cannot accept “the CoC” for the Ruby community(bugs.ruby-lang.org)
bugs.ruby-lang.org
Matz: I cannot accept “the CoC” for the Ruby community
https://bugs.ruby-lang.org/issues/12004#note-95
9 comments
Weird title: He can accept "the CoC", not just the draft in that thread, he wants a few changes (no banning, for example, people may want to change their minds), and then he proposed a slightly reworded CoC that has his changes, that's all
I frankly can't understand how the OP's first response after Matz's CoC rough draft is "now let's talk about enforcement." The priorities seem misconstrued to me.
It's the clearest window into the intent of the OP.
A fun exercise:
Look through all the CoC supporters, and see how many bugs they have filed.
Then for added fun, see how many of the supporters of a CoC have even commented on other threads.
This is the very definition of astroturfing.
Look through all the CoC supporters, and see how many bugs they have filed.
Then for added fun, see how many of the supporters of a CoC have even commented on other threads.
This is the very definition of astroturfing.
I don't like to comment on these types of threads on HN, but the same names pop up in the same type of comments, bugs, or whatever various flavor of the day for whatever software someone notices today.
I don't think everyone who submits a bug needs to be a significant contributor to a project, but when someone says they want to create a set of rules (that later in the thread "should be treated as law") to regulate something that seems to be working, and that person is not a contributing member of the community, something is wrong.
I don't know what overall benefit we would have if every software project had a CoC(which seems to be their goal), it's like asking all of us to bundle one with your birth certificate.
I don't think everyone who submits a bug needs to be a significant contributor to a project, but when someone says they want to create a set of rules (that later in the thread "should be treated as law") to regulate something that seems to be working, and that person is not a contributing member of the community, something is wrong.
I don't know what overall benefit we would have if every software project had a CoC(which seems to be their goal), it's like asking all of us to bundle one with your birth certificate.
Just to answer the question, Exactly ONE (1) developer had posted in a legitimate prior bug.
There were over ten people in the thread supporting the OP.
There were over ten people in the thread supporting the OP.
The discussion is a good thing. There are some dangers in blindly adopting draconian Cider House Rules, because, for instance, they can be gamed as cudgels to throw out individuals for any reasons rather than promote healthy debate and social give-and-take.
True. I actually liked the progreqsl one that was liked in the thread.
Yeah, me too.
-1. There is legitimate trolling, harassment, drama and d!ck moves that need to be handled with decency, common-sense and least bad measures... in open societies in real life, specific laws and enforcement haven't yet been able to eliminate #sshole behavior... it's usually handled socially. Sure it's different, but there's got to be some common sense and due-process, rather than instahellban of a core dev because someone new makes a bogus accusation.
0. Folks should try to calmly stand up to bullyvictim behavior and excessive microagression drama.
1. On large projects facing mostly public / non-enterprise / younger users, there could be need for formal training of project leaders or designated third-parties in conflict resolution / mediation to make peace, where possible. (Maybe open source conflict resolution as a service would be a viable startup? IDK, or a pockethotline perhaps?)
2. 37signals showed less anonymous participation increased kindness and reduced toxic behavior... perhaps projects should link accounts to G+ / Facebook / Github?
3. A risk of blindly adopting CoCs is that a new, amorphous bureaucracy of unknown persons/governance itself gains a foothold into many projects, and may come back and start asking for compliance reports, more control and more changes. Some of this might be good, but it could become more about browbeating others into bending to their will a-la Yale screaming girl https://youtu.be/9IEFD_JVYd0
4. Popularity of a behavior or trend is not necessarily equivalent to an ethical and/or wise change, but it is worth discussing.
5. Paraphrasing subversion folks An undefended community ceases to be the latter.
-1. There is legitimate trolling, harassment, drama and d!ck moves that need to be handled with decency, common-sense and least bad measures... in open societies in real life, specific laws and enforcement haven't yet been able to eliminate #sshole behavior... it's usually handled socially. Sure it's different, but there's got to be some common sense and due-process, rather than instahellban of a core dev because someone new makes a bogus accusation.
0. Folks should try to calmly stand up to bullyvictim behavior and excessive microagression drama.
1. On large projects facing mostly public / non-enterprise / younger users, there could be need for formal training of project leaders or designated third-parties in conflict resolution / mediation to make peace, where possible. (Maybe open source conflict resolution as a service would be a viable startup? IDK, or a pockethotline perhaps?)
2. 37signals showed less anonymous participation increased kindness and reduced toxic behavior... perhaps projects should link accounts to G+ / Facebook / Github?
3. A risk of blindly adopting CoCs is that a new, amorphous bureaucracy of unknown persons/governance itself gains a foothold into many projects, and may come back and start asking for compliance reports, more control and more changes. Some of this might be good, but it could become more about browbeating others into bending to their will a-la Yale screaming girl https://youtu.be/9IEFD_JVYd0
4. Popularity of a behavior or trend is not necessarily equivalent to an ethical and/or wise change, but it is worth discussing.
5. Paraphrasing subversion folks An undefended community ceases to be the latter.
> Examples of unacceptable behavior by participants include: ... Other unethical conduct
This example is a bit... spongey.
This example is a bit... spongey.
The vagueness of terms and undocumented extent of what is part of 'participation in this project' are what I think a lot of people are having issues with.
The same drama has been playing out in the php community for the last few weeks.
Pretty solid and thoughtful response. Almost makes me want to learn Ruby. Almost.
I've seen too much "CoC" for one day. Goodnight HN.
> Our community have 20+ years of history. We had a few issues in the past, but all of them could be resolve by the communication.
> On the other hand, we had to take great care to avoid bureaucracy in our workflows and processes. For me, avoiding bureaucracy is far immediate danger. Of course, I agree with you in part, so I agree to add kind of CoC for the community.
Matz agrees with a CoC, but sees the Contributor Covenant as heavy-handed. Nothing wrong with that, no need to give this a title that's totally wrong.