Cidram: Community Code of Conduct

[Maikuolan]

Request For Comment: Community Code of Conduct.

We haven't particularly needed anything like a "Code of Conduct" in the past, but it's possible that such a thing may become useful in the future as participation in the project and the community around it grows.

Many much larger, professional, and more popular projects and communities have similarly adopted their own versions of a "Code of Conduct" as a means of maintaining positive, healthy conduct within those projects and communities.

In addition, as the saying goes: Better to have it and not need it, than to need it and not have it. :-)

I've pushed an initial draft commit for a Code of Conduct for us as follows:

CIDRAM Community Code of Conduct

Our Pledge

We as participants, members, contributors, and maintainers pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people.
• Being respectful of differing opinions, viewpoints, and experiences.
• Giving and gracefully accepting constructive feedback.
• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience.
• Focusing on what is best not just for us as individuals, but for the overall community.

Examples of unacceptable behavior include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind.
• Trolling, insulting or derogatory comments, and personal or political attacks.
• Public or private harassment.
• Publishing others' private information, such as a physical or email address, without their explicit permission.
• Other conduct which could reasonably be considered inappropriate in a professional setting.

Enforcement Responsibilities

Community maintainers are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community maintainers responsible for enforcement at [INSERT CONTACT METHOD]. All complaints will be reviewed and investigated promptly and fairly.

All community maintainers are obligated to respect the privacy and security of the reporter of any incident.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.

Source: https://github.com/CIDRAM/CIDRAM/commit/10c0ec3505d342fc64c4085c499709e037cb4730

Per that commit's description:

• Adapted from the Contributor Covenant, version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
• This is an initial, draft commit only (a chance for review by the community, and possible further discussion, should be provided before merging this commit to any stable branches).
• To-do: Replace [INSERT CONTACT METHOD] placeholder with an actual contact method (haven't decided yet exactly which contact method would be best in this context).

My main concern with that last part (about the contact method) is whether to use an email address of that purpose or some other means of contact. In the case of the former, I have some concerns about explicitly publishing an email in plain-text anywhere at the repository, due to the risk of spam and other similar risks. In the case of the latter, it's just a matter of deciding which would be the best way to go (which is something that I don't have particularly strong leanings for at the moment, one way or the other).

In any case, this issue has been created to provide an opportunity for others to review the draft and provide feedback. Pull requests directly to the newly created branch as a means to suggest changes is also welcome, if anyone would like to do that. Anyone is welcome to participate at this issue here, too.

For those that also participate at phpMussel: I'm creating a parallel issue there, to similarly implement a possible "Code of Conduct" there. That issue there will have almost identical content to this issue here, but the two issues should nonetheless be treated as separate issues, due to that they concern two separate projects/organisations. Feedback and comments that apply equally to both issues are welcome at both issues, and may also be posted in parallel if so desired.

I'm not demanding any particular deadline for this RFC; We'll consider this issue "closed" when we decide we're ready to do that, so there's no stress and no rush in that regard. :-)

[DanielRuf]

Spam is the least / smallest issue / risk. Nothing I would care too much about.

So far as a maintainer I have also received such reports via email and not much spam so this is ok. And a way which others often choose.

[ghost]

@Maikuolan Scope creep warning.
It's _totally_ unnecessary to start mucking around with such, as each platform we use have it's own Terms Of Service regarding anything from acceptable use to disclaimers.

If we're becoming another legal department then "I'mouttahere". _Just sayin'._

[DanielRuf]

No this is not unnecessary imho. A CoC makes much sense.

These often define rules which are not in the mentioned disclaimers and this is more community related.

Also see https://github.com/CIDRAM/CIDRAM/community

[ghost]

@Maikuolan I'm drop dead serious about it. No need to laugh.

[DanielRuf]

Well, all members should be fine and comply with these rules too.
Are you ok with these?

Because otherwise we may have to resolve this conflict.

But making an exception just because of one person and applying no CoC is not great.

There are good reasons for such a CoC that I do not want to explain in detail now.

[Maikuolan]

If we're becoming another legal department then "I'mouttahere". Just sayin'.

Fair call, and it's definitely not my intention, that we end up becoming another legal department (figuratively or literally alike), nor my intention to drive anyone away or discourage participation at all. '^.^

It's _totally_ unnecessary to start mucking around with such

Also true. And, another reason why it's good to sometimes do RFCs/votes/suggestions/etc instead of just going ahead and unilaterally deciding these things myself, and I appreciate the feedback on these things. :-)

To clarify intent: I'm also not aiming to create any additional responsibilities or complexity to the project, either; I'm more looking at something to cover the common sense stuff that we already know and we're already doing (i.e., that we're already able to delete/edit stuff if we feel it's necessary, that we'll probably feel it's necessary if it's something that makes the project look bad and so on). What I'm basically envisioning with this is that once the CoC is implemented (if we get to that point and it ends up being implemented), that nothing really changes at all, but having the CoC would mean that nobody should be surprised about how we maintain/moderate/deal with content/comments/interactions/etc here in the event that we end up needing to deal with something in that way in the future. Also somewhat bandwagoning on a number of other projects/organisations at GitHub already doing the same thing, encouraged onto doing so by this.

[Maikuolan]

(Sorry about the laugh react; Getting a bit sleepy at the moment at my end of the world. I've changed it to a thumbs up :+1:).

[Maikuolan]

But yeah; Something which causes conflict between maintainers/contributors to the project, or which points the project in a direction that doesn't agree with current maintainers/contributors to the project (e.g., you, me, etc) is totally opposite to my intentions, so I don't plan to merge anything here until it starts resembling something we're all reasonably happy with (or, in worst case scenario, not at all). If others are generally against it, that's fine (that's part of the discussion, too). Depending on whether we're talking being against the idea entirely, or just against a particular aspect of it, we can always modify it into something more agreeable, strip out anything seen as unnecessary and so on; no problem there.

[mikeruss1]

I find it difficult to have a comment, it feels OTT, but if you reckon its necessary then no problem.

[Maikuolan]

I'm going to close this off and mark it as abandoned for now for four main reasons:

1. Negative responses to what the RFC proposes.
2. Since my own account is the only one with owner status for the CIDRAM organisation here at the moment, standard enforcement procedures for theoretical incidents don't really make much sense right now (i.e., nobody else needed to confer with if I was to enforce something, and not really useful anyway if I was the person in question myself, since there would be nobody else to enforce it).
3. No precedents, nothing has happened, ergo, no evidence that it's really needed at the moment (just something which would look nice, and which GitHub recommends to be implemented to GitHub organisations).
4. Issue is stale (last activity more than a year ago; don't foresee any immediate reasons for activity to resume here).

But, if circumstances change in the future (e.g., incidents happen, new owners are brought into the fold, we suddenly see a massive unexpected influx of participation here, etc), well.. there's no reason we can't just reopen this and explore the idea again in the future when needed.