Updates to the Julia CoC

[logankilpatrick]

Hey @JuliaLang/stewards,

I think it would be worth iteratively working on making the CoC more robust. In particular, I think we should update the text to include the mention of the need to make things open as well as add a diversity statement.

I like the NumPy openness statement:

Be open. We invite anyone to participate in our community. We prefer to use public methods of communication for project-related messages, unless discussing something sensitive. This applies to messages for help or project-related support, too; not only is a public support request much more likely to result in an answer to a question, it also ensures that any inadvertent mistakes in answering are more easily detected and corrected.

As an OSS project, it makes sense to state this explicitly.

We should also add a dedicated diversity section on the CoC re-affirming our commitment to making the Julia ecosystem a place where everyone is welcome. Right now, the "inclusion" statement is bundled with the "be respectful" section which I think should be split.

[jiahao]

Thank you for taking the lead on this language change. Cross-referencing a relevant Slack thread for context.

Summary of issues discussed

• Pile-on behavior should probably be discouraged.
• A "no politics" rule is not neutral, but rather reinforces the status quo, silences the marginalized, and makes it harder to advocate for positive change.
• The existence of marginalized people (e.g. nonbinary, trans, ethnic minorities) is inherently politicised.
• Diversity and inclusion of people, not opinions. Sometimes it's necessary to call out behaviors and statements to the contrary. (c.f. Popper's paradox of tolerance)
• A healthy community has to balance needs for robust communication, offering support, and be willing to improve, adopt best practices, and experiment with new ideas to advance diversity, equity and inclusion goals.

[logankilpatrick]

One thing came into my mind . That whenever we make issue and after the issue is been solved it should be closed . So that it won't make any confusion for the new contributors and also experienced contributers who want to contribute.

So what I want to ask is that can we add this point in the CoC :

• After the issue gets resolved author should closed the issue .

Please do have feedback whether this point will work.

Thanks for the suggestion, I think given this is a standard OSS practice, we don't need to mention it.

[StefanKarpinski]

It also doesn't seem relevant to a code of conduct / community standards document — that's a logistical issue for a particular project.

[logankilpatrick]

I would also propose adding a few examples terms to avoid in the CoC such as "blacklist" and "whitelist". See here for example: https://github.com/JuliaInterop/Clang.jl/pull/302

[logankilpatrick]

Any thoughts on how to push this forward? If we (@jiahao, I , and others) put a PR in and request feedback from the community as a whole + stewards, is that fair or is there a different way to approach this?

[stevengj]

I would encourage a set of small self-contained PRs rather than a single big one if possible. For example, a small PR to rename black/whitelist is likely to be relatively uncontroversial. A separate PR for a diversity statement. Etcetera.

[StefanKarpinski]

It makes sense to me to specifically call out diversity but it seems like the current "be respectful and inclusive" already aims to do that without specifically mentioning the word "diversity". I agree, however, that it could probably use some rewording, including using the word diversity explicitly. An example of weird wording in the current document is that attacking someone for any reason is bad, so that wording choice is a bit off. Several of the items in @jiahao's list seem like they would apply to specific forums, not the Julia community in general:

• Discouraging pile-on behavior does make sense but feels a bit specific for such a high-level document. Discourse has a pile-on problem but GitHub generally doesn't.
• There is not any blanket "no politics" rule in the community standards, that's just an informal rule to try to keep things from getting heated on Slack. Enshrining "no politics" or "yes politics" in the community standards seems inapprpriate to me.
• "Diversity and inclusion of people, not opinions" is a good and completely general point that does very much seem like it should go in the community standards somewhere. There's also the point that you sometimes moderate or even ban people because for the greater sake of inclusiveness even though that excludes those specific people.

I also wholeheartedly agree with @stevengj's suggestion of making a series of smaller changes so that each can be considered and merged or rejected independently.

[StefanKarpinski]

I would add that the reason the section that addresses diversity is entitled "Be respectful and inclusive" is that it would be nonsensical to instruct people to "be diverse". We want to foster a diverse community, but you can't tell people, as individuals, to be diverse. So that section is effectively the commitment to diversity, but since the document is expressed in terms of what an individual should or shouldn't do, it's expressed that way. It would, however, make sense to call out diversity as an explicit goal in that section.

[KristofferC]

For example, a small PR to rename black/whitelist is likely to be relatively uncontroversial.

This could be done to the different Julia community pages but I don't think it is worthwhile nor desirable to go around making PRs that blindly search and replace terms in a bunch of open source packages. One reason for this is that unless you have worked with the package you do not really have the context to know if your search and replace breaks something. For example, https://github.com/JuliaLang/SuiteSparse.jl/pull/36 would introduce a bug in the package. And https://github.com/JuliaInterop/Clang.jl/pull/302 is a breaking change without any discussion of how that should be handled.

So ok to do this type of change to the official community pages but let's not start grepping through the ecosystem for different terms and make search-replace PRs.

[logankilpatrick]

@KristofferC I understand your point and perspective