Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A CoC for Raku #136

Draft
wants to merge 18 commits into
base: master
from
Draft

A CoC for Raku #136

wants to merge 18 commits into from

Conversation

@lizmat
Copy link
Member

lizmat commented Nov 28, 2019

As an attempt to resolve #134

lizmat added 3 commits Nov 26, 2019
This is essentially a markdown version of

   https://raw.githubusercontent.com/perl6/specs/master/S27-perl-culture-draft.pod6

with s/Perl 6/Raku/, intended as a starting point to further alterations and
additions to make it up-to-date and applicable to today's realities.
Copy link
Member

AlexDaniel left a comment

I like it.

solutions/meta/CoC.md Outdated Show resolved Hide resolved
solutions/meta/CoC.md Outdated Show resolved Hide resolved
solutions/meta/CoC.md Outdated Show resolved Hide resolved
solutions/meta/CoC.md Outdated Show resolved Hide resolved
solutions/meta/CoC.md Show resolved Hide resolved
lizmat added 4 commits Nov 30, 2019
So it becomes:

  We discriminate on the ability to be a kind, positive member of our community
This indeed appears to be written in an era where trolls really were a major
issue for Raku.  After the change of name to Raku, this appears to be a lot
less the case.  So no reason to actually emphasize something that is quickly
becoming a historical artefact.
It feels very Perlish / TimToady-like.  And hard to understand if you do
not know the background of Raku and its long gestation process.
@japhb

This comment has been minimized.

Copy link

japhb commented on 594c2e0 Nov 30, 2019

Perhaps "We only discrimate"? It's important we make it clear that the base expectation is not discriminating.

@japhb

This comment has been minimized.

Copy link

japhb commented on 37204bc Nov 30, 2019

Hmmmm. This one is debatable because I worry about people saying "I was just having a bad day! You should totally forgive me for [insert unacceptable behavior here], and I shouldn't need to apologize for just having a bad day!"

This comment has been minimized.

Copy link
Contributor

vrurg replied Nov 30, 2019

@japhb Yes, anybody can say so. But in either case in areas like this it is often that things are unprovable on a basis of a single case. But two-three repeated cases would make it a statistics and a reason not to believe to the excuses.

This comment has been minimized.

Copy link

japhb replied Nov 30, 2019

Note: @lizmat addressed my concerns (and maybe yours?) in a later commit.

@japhb

This comment has been minimized.

Copy link

japhb commented on f2b2694 Nov 30, 2019

Should we have something about not using "assume good intentions" as a form of deflection/derailing? I'm talking about cases where person A does something WBA, they get called on it, and person A tries to deflect/derail by telling the people who called them on it that they have to assume person A had good intentions?

I've seen this "weaponized" by those who are somewhere between acting culturally insensitive and actively trolling, and who are aware the local CCoC has a good intentions clause -- and use that to try to excuse not accepting/learning from any feedback about how to work well with others. This is closely related to the "I shouldn't have to learn how to communicate kindly, they should have a thicker skin" excuse.

Edit: Clarified first sentence of second paragraph that I'm talking behavior and not intrinsic attributes of a person.

@lizmat

This comment has been minimized.

Copy link
Member Author

lizmat commented Nov 30, 2019

I think the "weaponizing" part is inherent on having a CoC. As soon as something is written down, instead of a unspoken mutual understanding of what is acceptable and what is not, you will get people "gaming" the system.

Perhaps this could be under the troll heading, because that's basically the definition of a troll: that they do not have good intentions?

lizmat added 2 commits Nov 30, 2019
Definitely *not* happy with the wording yet.  Throwing it out there for
feedback.
@vrurg

This comment has been minimized.

Copy link
Contributor

vrurg commented on 21c86e1 Nov 30, 2019

Not sure if it really belongs here. Community in general is bigger than just Rakudo core development. Each subproject can have its own guidelines and that's fine. Perhaps, this is what this section has to be about (in "pseudo-code language"): Follow the guidelines of the project you contribute to. Breaking the guideline rules is considered a form of trolling.

This comment has been minimized.

Copy link

japhb replied Nov 30, 2019

I agree, this commit feels "off"; especially the last sentence doesn't sound right. To me it seems a bit like "If you aren't willing to be responsible for literally the entire ecosystem, we won't accept your changes and we'll just revert you if you try." That sets the bar too high for contributors just trying to make a small improvement.

I think @vrurg has a point in his comment, that we want to speak more generally in the community-wide CoC doc, although I do want to be careful to separate "innocently unaware of all the rules" from active trolling; otherwise we become unfriendly to beginners. Maybe "Follow the guidelines of the project you contribute to. We're happy to assist beginners to learn the ropes, but repeated violations of guidelines you've already received feedback on can be very frustrating for our friendly volunteers." Hmmm, still feels a bit off, but not sure in what way.

As for the Rakudo specifics: I do think people hacking on core code should be responsible for making sure their changes pass internal tests and roast -- they exist for exactly that reason, after all -- and I think core hackers should also be responsible for following the compatibility rules that we've already set down. However, I'm unsure about ecosystem responsibility.

Ecosystem authors often have to take time away from the Raku community for extended periods, and it may be difficult to reach some of them even to accept a PR. It may be worth having a policy for that situation as well (though almost certainly in a separate document, because I think that's more about procedure for dealing with unhealable ecosystem problems than behavior/conduct).

@lizmat

This comment has been minimized.

Copy link
Member Author

lizmat commented Nov 30, 2019

Yeah, I wasn't too happy with the wording either, as I stated in the commit message. It's getting quite late here now, and I feel this is not the best time for me to work on this (as evidenced by the last commit). Thanks for your feedback, will get back to it tomorrow.

solutions/meta/CoC.md Outdated Show resolved Hide resolved
solutions/meta/CoC.md Outdated Show resolved Hide resolved
@AlexDaniel

This comment has been minimized.

Copy link
Member

AlexDaniel commented Nov 30, 2019

Discussion regarding code breakage and rakudo release management: https://colabti.org/irclogger/irclogger_log/raku?date=2019-11-30#l303

solutions/meta/CoC.md Outdated Show resolved Hide resolved
@AlexDaniel

This comment has been minimized.

Copy link
Member

AlexDaniel commented Nov 30, 2019

@lizmat++, this document is great and it's becoming even better. I am amazed at what you did with the Path to Raku document, and I'm glad you're now working on this. Thank you!

Copy link
Member

ugexe left a comment

Re: Responsibility

I agree this all is a bit specific... maybe like the CoC itself everything shouldn't have to be defined so rigidly. With that said, for brevity, some bullet-point style description of being a reponsible developer might be something like:

  • Spend time understanding changes you are making that the public will consume -- this includes code you merge

  • Know when to ask someone more knowledgeable than yourself to look over code via PR

  • Take responsibility for things you broke; avoid parroting patronizing phrases any recipient will already be aware of (such as "PRs welcome")

  • Leave a descriptive commit title and message that allows other developers to understand the "why"

  • Uses branches and squash fixup commits as appropriate

Now of course this should all go without saying, but if it did I personally wouldn't be having any issues. And honestly yeah its fine to bend some of these rules sometimes -- but this type of example inevitably leads others to follow, and those others might not be as detailed oriented as yourself. I would agree missing one of these points probably isn't a big deal in itself, but if someone is breaking most/all of those points repeatedly then that is crossing over into negligence (which is what has me upset).

Imagine someone making 20 commits, all of which don't have a description and only refer to a git issue in the title, with changes that are not fully understood, merged all directly to master, and the submitter pulls the "PR welcome" card when the mistake is pointed out. This possibly theoretical scenario is indicative of negligent conduct -- it is well beyond the point of asking someone to add a proper git message. This culmination is the situation I am trying to prevent in the future, not e.g. making sure everybody uses branches.

I don't have any better suggestions for wording. Again, I think it should be similar to the rest of the CoC where specific actions don't need to be spelled out. It just needs to discourage negligent behavior and have the same repercussions of unacceptable "social" behavior (social in quotes because everything I listed is also technically social).

@@ -7,7 +7,7 @@ What's discussed in this document boils down to this:

* We aim to be actively welcoming, friendly, respectful, and helpful to everyone interested in Raku and our shared community.

* We discriminate on the ability to be a kind, positive member of our community.
* We **only** discriminate on the ability to be a kind, positive member of our community.

This comment has been minimized.

Copy link
@nxadm

nxadm Dec 1, 2019

Member

This is not better as it not address the problematic formulation. You're talking about how kindness is appreciated while discrimination is about structural and systematic action, even positive discrimination. So when people are nice they will structurally be given chances in order to eliminate a historical injustice? Or when unkind no chances will be given, in a silent yet systematic way?

As you can see, the choice of words is very problematic. I would remove the sentence because it sense (asking for kindness) is already part of the previous point:
"We aim to be actively welcoming, friendly, respectful, and helpful to everyone interested in Raku and our shared community."

This comment has been minimized.

Copy link
@lizmat

lizmat Dec 1, 2019

Author Member

Is this addressed by e2b18bf ?

@lizmat

This comment has been minimized.

Copy link
Member Author

lizmat commented Dec 1, 2019

I can only think of one thing that perhaps would need to be added to this document: how community arbitrators are made available for settling disputes. In a way, I think that this should probably not be part of the CoC: since arbitrators should be acceptable to both parties, there can not be a case of being assigned an arbitrator that is not acceptable.

Things get harder of course when there are no arbitrators willing to take on a dispute, even if they would be acceptable by both parties. Should that be in the CoC?

@japhb

This comment has been minimized.

Copy link

japhb commented on e2b18bf Dec 1, 2019

Hmmm. I'm not sure whether we should try to list all the individual things we won't discriminate on. On the one hand, it does make clear we are affirmatively, explicitly protecting each of the listed groups, and I think that's a positive. On the other hand, such lists are pretty much always incomplete; this leaves some people feeling unprotected, and gives fuel to prejudice towards unlisted groups.

If we're going to give details like this, it ought to at least include a larger list of protected groups. The list of US federal protected groups includes a lot more categories, and that doesn't even include the extra protections afforded in jurisdictions ranging from California to the EU.

This comment has been minimized.

Copy link

tmtvl replied Dec 1, 2019

Can't we just provide a copy of the universal declaration of human rights and be done with it?

This comment has been minimized.

Copy link
Member Author

lizmat replied Dec 1, 2019

This comment has been minimized.

Copy link
Member Author

lizmat replied Dec 1, 2019

This comment has been minimized.

Copy link

japhb replied Dec 2, 2019

@lizmat I see you added a few more in later commits, but FWIW I was also thinking of disability, military/veteran/civil service status, employment status and employer if any, religious (or non-religious) affiliation, race/color (though you partially address that last one with ethnic/cultural background), and so on.

And that's just off the top of my head. To be clear, I wasn't saying "don't do this", just that it's harder than generally expected to be truly inclusive when listing individual axes of human differences. That's why the original wording (and your first commit that removed the double-negative) didn't even try to give an exhaustive list. But I recognize I made that decision back in 2015, and times have changed a bit.

This comment has been minimized.

Copy link
Member Author

lizmat replied Dec 2, 2019

This comment has been minimized.

Copy link
Member

duncand replied Dec 2, 2019

If we want to be truly inclusive, we shouldn't list anything. I hoped that saying "ethnic / cultural" background would cover the religious / race / color / social status / employment / veteran thing. With the addition of "technical background", I think we've covered language tribal utterences. The only one I have doubts about adding, is "physical ability". But since almost all of this is done on-line (on the internet, nobody knows you're a dog), that feels more for an event CoC, then for a community CoC.

The initial diff seems very imbalanced if a long list of qualities typically spelled out in full is grouped implicitly into "ethnic/cultural" while at the same time "gender, gender identity" are each individually spelled out separately; it reads like those 2 are a focus and the rest is an afterthought.

I feel that either we should not enumerate protected classes at all or we should take the official legal protected classes of any countries we wish to emulate and union them. But I fall on the side of not enumerating at all.

This comment has been minimized.

Copy link
Contributor

vrurg replied Dec 2, 2019

@lizmat I agree to you on this. After all, this is not a legal document.

I can't formulate it correctly to myself, but it feels that something like: "We don't discriminate on anything but karma. And the karma is formed by how to treat the people next to you." – sounds about right.

@ugexe

This comment has been minimized.

Copy link
Member

ugexe commented on 7004ecc Dec 2, 2019

🎵 One of these things is not like the others... one of these others is not the same 🎶

This comment has been minimized.

Copy link
Member Author

lizmat replied Dec 2, 2019

solutions/meta/CoC.md Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.