Add code of conduct #7151
Add code of conduct #7151
Conversation
This adopts the Contributor Covenant Code of Conduct. There's no email address given because we do not, currently, have a project email address that I'm aware of.
|
Nice, it's a good idea to add a code of conduct. |
|
I'll just leave this here: https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-Code-of-Conduct-2020 |
@neheb I'll admit I have no idea why you're leaving it there. |
|
This CoC was disliked by many FreeBSD users. That's why. |
It's not the same? https://web.archive.org/web/20180213113526/https://www.freebsd.org/internal/code-of-conduct.html is the old FreeBSD one. This one is quite substantially different. The old FreeBSD CoC was based on something from the Geek Feminism Wiki, this is based on the Contributor Covenant. |
|
Is there actually a need for this though? |
|
@R2robot This is where I'm coming from: https://drewdevault.com/2020/01/17/Effective-project-governance.html |
|
Having suggested this (in private, which is certainly less helpful) some years ago, I am strongly in support.
As a professional in a tightly regulated occupation, and an active volunteer with a number of formal organisations, it really surprises when participants in a moderate-sized volunteer project don't agree on a (very basic) standard of behaviour. It seems like releasing an open source project without a license. There have not been any public incidents requiring the enforcement of a code of conduct but after an incident is the worst time to realise you need to lay out some expectations. In the wider community there have been a number of members of marginalised groups who have indicated the importance of a code of conduct. In my view (and I'm happy to be told otherwise, publicly or privately) regular contributors and committers generally adhere to the standards set out in this patch, and I don't see that is creates an onerous obligation to participate. On the other hand, I hope that it will provide what mjg59 calls "a list of behaviours that are unlikely to occur within that community". |
|
Fair enough. I guess I am just naive enough to trust participants in our established community to stay civil. Although the kind of people who would make hurtful comments are likely to knowingly ignore code of conduct anyway. On that note, perhaps it should mention specifically how one can contact the project team, especially for those who would rather keep the reporting itself private. If there's no project email address, then could gitter be used instead? (Assuming it has private messaging?) |
You know, I used to think that as well. I was wrong, and I apologize for it. Because there is very much disagreement on what "civil" (if that's even the right word) means. There are a lot of places on the internet where, for instance, transphobic behavior is considered acceptable. And so, by adopting a Code Of Conduct that says so, we make it clear that this is not one of those places.
The template github provides includes "contact the project team at ". I left it out because we don't currently have such an address. We might want to create one.
Reporting should obviously be confidential.
I'm not sure about that - gitter is another service that you need to agree to the ToS of, it requires another account,... Email is ideal because everyone already has it. |
Well I guess that's decided then :P |
|
I don't see anything that could be considered objectionable in the proposed CoC. As an old-school denizen of teh interwebs, I too like to continue to believe in the innate goodness of people but I think it's important to distinguish that technical and ethical competencies do not necessarily go hand-in-hand. While the internet of old was in many ways a meritocracy and the majority of BDFL-led organizations absolutely have avoided doing anything that goes beyond the line that divides being politically incorrect from being a bigot/bully, it is important to acknowledge that there are absolutely are communities that have fallen victim to being unable to either see or act when such inappropriate behaviour did arise because it came from individuals who either were or had become too valuable to chastise. If such a code of conduct makes it clear to both members of a project and others interacting with the organization or using its product that they can expect at least some level of decency, I don't see why not. Basic decency aside, it is in the best interest of the community/organization itself and the spread of its product/ideology to be positively perceived in the community and to be a force of good, not evil. As to this specific CoC being proposed in this PR, I think it's fine. I think having one is better than having a perfect one and obviously (as mentioned) organizations will ultimately do what they want but even if they either have an incomplete CoC that doesn't go into each and every do/don't or else choose to be lenient and give second chances for repeat offenders, the fact that the CoC is there, is agreed to by all contributors/members, and hasn't been repealed in a revert commit says volumes about the principles of an organization. If this CoC were to go into the nitty-gritty and delve into controversial specifics like refraining from using certain terminology because of perceived etymological origins or requiring a rewrite to enforce certain grammars or whatnot, I could see why people might be up in arms about it. But this is about as harmless and uncontroversial a CoC as one could find and I'm more than happy to see it added. That said, I would be extremely disappointed if this repository were to become a politically charged environment that invites controversy where none existed by needlessly splitting hairs or requiring people to take a stance on every issue that comes up, but I see no reason to think that would become the case. I assume the best of faith and believe that no one will take this as an opportunity to do that, and would hope others can see the merit in the same, regardless of where they stand on any issues. (Now with my developer hat on however, I do have nitpicks about the line wrapping inconsistencies and would certainly love to see a |
This is from a template github provides. I would assume keeping it the same to ease diffing to be more important than minor formatting nitpicks. |
|
On the mailing list, Pim Dennnendal asks: "Why not adopt v2"? |
This has some rewordings and includes more specifics on enforcement, but it's roughly in the same spirit. Note that this still includes the contact method stub, which would have to be filled in.
Because Github still provides 1.4 as the template. I've now upgraded to 2.0. Note that, as the commit message states, this includes an "[INSERT CONTACT METHOD]" stub that we would have to fill in. |
|
Why is the file format Markdown instead of reST? Related PR: #7057 |
|
Again: Because that is the format this is provided in, and we want to allow diffing with the original. |
There was a problem hiding this comment.
I am no expert on this matter; yet this code of conduct looks nice and
non-controversial since it is aligned with how regulars around here are acting
already.
Occasionally there are rude comments, mostly when the parties involved in
the conversation come from very different backgrounds.
Pointing community members who overstep boundaries to this document
seems useful, just like with regular documentation.
Beyond that, I believe it is beneficial to moderate hurtful comments:
a) if they contribute nothing to the discussion, to not waste time and energy.
b) to avoid that bystanders think bad manners are acceptable here.
Even though it feels dishonorable to limit someone else's freedom of expression.
(I'd do a sed '1d;$d' but since this is what upstream provides, by all means, leave it.)
|
@faho I understand. Thanks for answering. |
|
Thank you for taking the lead on this @faho and apologies for my absence on this matter as I took a bit of a GitHub break. I also am very strongly in support, I wish we had done it a while ago and regret not taking action when zanchey raised it privately. Regarding the contact method stub, I am not sure how other OSS projects manage it. I think it would be OK to delete that sentence for now, or just link to |
|
Okay, merged as 0b3b4f3. That's it, then. |
This adopts the Contributor Covenant Code of Conduct.
There's no email address given because we do not, currently, have a project email address that I'm aware of.
TODOs: