Adding Contributor Covenant Code of Conduct

[tapaswenipathak]

Hey maintainers: Can the project has Contributor Covenant Code of Conduct added https://en.wikipedia.org/wiki/Contributor_Covenant?

[sbrl]

Hey, @tapaswenipathak! Currently, we use @CLAAssistant to provide a license agreement thingy. What's the difference between the document you are referring to and the one we have already?

Ping @waldyrious, @agnivade, @pxgamer, @mebeim.

[agnivade]

@sbrl - It is a code of conduct. The CLA assistant is just for the CLA.

AFAIR, we haven't seen any issues of abuse or conflict in our community before. Everyone here is friendly and welcoming. I think as far as CoC goes, GOVERNANCE.md is the closest we have.

@waldyrious is the expert in these matters. I will leave it to him to decide whether a CoC is warranted or not.

[tapaswenipathak]

Hey @sbrl, quoting:

Open Source has always been a foundation of the Internet, and with the advent of social open source networks this is more true than ever. But free, libre, and open source projects suffer from a startling lack of diversity, with dramatically low representation by women, people of color, and other marginalized populations.

Often it is the unintentional assumptions and actions of project maintainers and participants that make open source projects unwelcoming (or even hostile) to marginalized people: making assumptions about gender or race, reinforcing stereotypes, using sexualized or otherwise inappropriate language, or demonstrating a lack of regard for the safety and well-being of vulnerable people.

One way to begin addressing this problem is to be overt in our openness, welcoming all people to contribute, and pledging in return to value them as whole human beings and to foster an atmosphere of kindness, cooperation, and understanding.

Adopting the Contributor Covenant can be one way to express and codify these values and signal your intention to make your open source community welcoming, diverse, and inclusive.

ref: https://www.contributor-covenant.org/. I like her work. I like open source and was thinking of getting involved in the project. Based on my experience I am thinking of no contribution in a open source project till they have a Contributor Covenant Code of Conduct.

As an information @agnivade Contributor Covenant Code of Conduct is different than a code of conduct and that is the worst scenarios that you have told. I would suggest giving a read Contributor Covenant Code of Conduct.

Please feel free letting me know if I can help in anyway in making you folks add a doc like Contributor Covenant Code of Conduct

[agnivade]

Oh my bad for not reading what is about. I just read it now and I think it spiritually matches what we had in mind while writing GOVERNANCE.md. Though it touches upon a lot of additional points that we missed. If there is a way to combine the Contributor CoC and what we have in GOVERNANCE, that would be great IMO. Otherwise a new document is also fine. Or maybe we can even subsume GOVERNANCE inside the Contributor CoC.

[waldyrious]

@tapaswenipathak thanks for reaching out about this issue. As you'll find out, we've always be quite mindful of these issues from very early on, and strive to keep our community open (as in transparent and democratic) and welcoming (as in friendly and empathic).

You might want to take a look at our GOVERNANCE.md, COMMUNITY-ROLES.md and Maintainers' Guide, documents all of which we've developed over time with these principles in mind, via open discussions with the community, and are living documents that are regularly updated whenever we identify shortcomings in them.

The Contributor Covenant is quite similar in spirit, but more focused on combating hostile behaviors especially towards groups of people who tend to suffer from unfriendly interactions more often. I think we could certainly adopt the Covenant by (1) adding the badge to the README and (2) editing the second principle of GOVERNANCE.md ("All interactions must be respectful and cordial") to specifically declare compliance with the covenant.

What do you guys think?

[mfrw]

What do you guys think?

+1 for the idea of adopting the CoC.

[mebeim]

Disclaimer: what follows is my personal opinion on the topic.

In my honest opinion, the Contributor Covenant CoC is not something we need.

I have never seen an issue in this repository that would require the adoption of such a code of conduct and the designation of an authority to contact for its enforcement (as the Contributor Covenant suggests). Granted that I have not been here for that much, I would ask other maintainers to either prove me right or wrong on this point.

The fact that this project welcomes contributions is pretty clear. We do not need an authority responsible for dictating what is and what is not ok, again as Contributor Covenant suggests.

What bothers me the most though, is that Contributor Covenant has had quite the history of abuse by people who use it only with the intention of pushing their political beliefs or even worse, hurting other people. Many examples can be seen of this and many valid points have already been made against CCCoC for this and other reasons.

• On the Proposed PHP Code of Conduct

• Beware the contributor covenant code of conduct

  • The scope of the Contributor Covenant was widened in an attempt to harass and ban Elia Schito for an opinion he had expressed on his personal twitter

  • The mantainer of this project should terminate the collaboration with the tech journal "Model View Culture" because is directed by a misandric person

  • Transphobic maintainer should be removed from project

I suggest you guys read what I linked above carefully before deciding to incorporate such a document in this project, because this is definitely not what I would want to have to deal with, considering that there have been zero political issues in this project so far.

Some people are saying that the Contributor Covenant is a political document, and they’re right.

-- Tweet from the creator of Code Covenant

---

Being welcoming and inclusive is good, but meritocracy is the ultimate and the only real solution for new people who wish to get involved (as our community roles also suggest).

I don't think this project needs CCCoC, and what we already have in GOVERNANCE.md, COMMUNITY-ROLES.md and maintainers-guide.md is perfectly fine. Furthermore, these documents already address issues that the CCCoC aims to solve, thus making it innecessary in this project.

Please bear with me if I made any mistake or wrote something that is unclear as English is not my mother tongue.

[waldyrious]

I understand where you're coming from, @mebeim. Thanks for voicing those concerns. To clarify, my position is as follows:

• I agree that we haven't experienced any issues that the covenant would address (nor even signs of an environment conductive to them happening).
• I agree that our various community guideline documents (and perhaps most importantly, the very culture imparted in the daily interactions of the project) already cover situations where the covenant would apply, albeit in a broader sense.

That said,

• Our guidelines make no specific mention of the kinds of hostility the covenant is aimed to address, even though they are founded on the same basic principles of respect and inclusion.
• We already have a team of maintainers and a way to contact it privately (as you may recall from our application to Season of Docs); and we would already have reacted to any private harassment or hostility reports pretty much in the way that the covenant suggests.

So in my view, nothing would be forced on us by agreeing to declare support to those specific guidelines; first, because we already apply the general principles behind them in practice, even if not documented explicitly; and second, because we don't even have those issues anyway (likely due to the first point, in fact).

Note that I'm not suggesting adding yet another guideline document to our project; I too would object to that, especially since the current texts have already proven to be (ironically! 😄) partially TL;DR in some instances. What I suggested was to simply add explicit signals that our existing adherence to the principles of inclusive and respectful interaction indeed is meant to also cover the situations the covenant focuses on — by making the language of point 2 of the GOVERNACE.md document more explicit (including a link to the covenant) and adding a badge to the README (or CONTRIBUTING.md, if that's more palatable). That's all.

As for politics, I frankly am not worried at all that such kinds of conflict could be injected into our project hinging of our explicit support for the covenant. I am quite confident in the ability of our community to handle toxic elements regardless of what our guidelines and other documents say. If we were vulnerable to such attacks, we'd be so with or without the covenant.

Of course, that's not to say I'm specifically advocating for the adoption of the covenant. I just think that if it helps reassure anyone that we're serious about maintaining our open and welcoming culture, then why not? And besides, if for any reason it ends up doing more harm than good, then we could just as easily remove it, following our usual process of community discussion and consensus.

[mebeim]

What I suggested was to simply add explicit signals that our existing adherence to the principles of inclusive and respectful interaction indeed is meant to also cover the situations the covenant focuses on — by making the language of point 2 of the GOVERNACE.md document more explicit (including a link to the covenant) and adding a badge to the README (or CONTRIBUTING.md, if that's more palatable). That's all.

Is that even an option? Adhering to said CoC without having it inside the project? It's a legally binding contract. Doesn't seem like it would make much sense. In the future the text of the document will change and we would need to keep reviewing it constantly to make sure it still meets our requirements.

Of course, that's not to say I'm specifically advocating for the adoption of the covenant. I just think that if it helps reassure anyone that we're serious about maintaining our open and welcoming culture, then why not?

I don't really see this need, from which perspective could this project not seem welcoming to someone? As you already said "this project has never experienced any issues that the covenant would address, nor even signs of an environment conductive to them happening".

Quoting from @tapaswenipathak's comment above:

Based on my experience I am thinking of no contribution in a open source project till they have a Contributor Covenant Code of Conduct.

This is exactly the kind of stuff I would not want to deal with. I don't even understand this point since you seem to have contributed to a good number of open source projects that do not follow CCCoC or even a CoC at all.

In short: the CCCoC has an history of people trying to push politics (and more) into things that really do not need it, and I personally wouldn't like being associated with it. The fact that I also see it as out of scope and unneeded is jut the icing on the cake. One can certainly have a CoC that agrees to the same basic welcoming principles without it being the CCCoC.

[principis]

(This is just my opinion as a small contributor who really likes this project. Please bear in mind English isn't my native language.)

I follow @mebeim in this. I don't see the need for this. I feel like this is a friendly informal community, which is nice. I'm really against adding a formal, controversial code of conduct which is said to be a political document. I feel like it clashes with the values this community tries to pursuit. I think staying as far as possible away from politically tinted documents is only in our best interests.

We already have a Governance document which contains everything, in my opinion, that should be in there. I'm not against changing part 2, but adding the covenant doesn't feel right in many ways.

As mentioned in some of the websites mebeim linked to, the document may be legally binding, and as such it could present this project with major troubles in the future.

Our guidelines make no specific mention of the kinds of hostility the covenant is aimed to address, even though they are founded on the same basic principles of respect and inclusion.

But do we need to mention the kinds of hostility? Don't the basic principles of respect and inclusion cover every kind of hostility possible?

[tapaswenipathak]

Hey folks: great going, let me know if you require any inputs from me, I will add inputs after you folks are w/ a decision. Happy discussing!

[agnivade]

Thanks for your inputs @mebeim and @principis. I find myself agreeing to both sides of the discussion here.

First of all, let me start off by saying that we as a community have always striven to go to great efforts to be welcoming and friendly. We always aim to thank the PR author and take special precautions to welcome a new contributor. All these are just written.

But beneath these is even a larger set of principles which are implicitly agreed upon. A great example is here. We decided not to close issues outright so that the issue creator does not feel offended. But there is no written agreement because we do not like writing down every single minutiae.

I strongly agree to what @waldyrious has mentioned here

I am quite confident in the ability of our community to handle toxic elements regardless of what our guidelines and other documents say. If we were vulnerable to such attacks, we'd be so with or without the covenant.

To address @principis' thoughts

But do we need to mention the kinds of hostility? Don't the basic principles of respect and inclusion cover every kind of hostility possible?

I don't think it is even possible to mention all kinds of hostility. But on the contrary, if explicitly mentioning it helps feel other people welcome, without adding additional overhead to us, then I think it's a win-win. A rule of thumb that I use while adding more guidelines is to check whether this is yet one more thing that I need to keep in mind before adding a comment. And the CCCoC is something so basic, I think everyone just follows it be default without having to even think about it.

At the same time, @mebeim's concern about CCCoc being legally binding is valid too.

@tapaswenipathak, could you clarify some of the concerns raised in this thread:

• Is somebody liable to be sued by someone for not following the CCCoC ?
• Is the doc liable to change in the future ?

To clarify, I whole heartedly agree with the "principles" of the CCCoC. But since I am a human being too, I might have a bad day and it might be possible that I unintentionally say something disrespectful. And I am afraid of the repercussions that might follow.

[mebeim]

Just wanted to clarify briefly since I did not made it clear enough in my previous comment:

Is somebody liable to be sued by someone for not following the CCCoC

That's very unlikely I would say, and also highly depends on your state. An USA citizen is not going to have a good time suing someone in Europe, for example. Still, o CoC has to be followed like CLAs or Licenses. When I used the words "legally binding" though I was more worried about the fact that adhering to it would imply that all of our contributors automatically adhere to it too, even without ever having seen it.

Is the doc liable to change in the future?

It's currently at version 1.4... so I would say this is rather obvious.

[waldyrious]

I fully subscribe to everything @agnivade said, so I won't repeat the same points.

Responding to some specific issues raised:

• Regarding the legal aspect: I'm pretty sure no meaningful legal action could be taken based on a declaration of adherence in a governance document, plus a badge on the readme; those would be merely informal (but truthful) signals that we as a community make explicit to the wider open source ecosystem that we aim to implement the covenant's principles (as we already do). I think the terms "legally binding" have very specific meaning that wouldn't apply here, as @mebeim himself clarified. That said, it is true that deciding to adopt the covenant would informally "bind" all contributors to follow it — but that's exactly the same level of compromise we require of any other guideline, the licensing agreement, etc. So nothing really changes here.

• I'm not against changing part 2, but adding the covenant doesn't feel right in many ways.

  @principis can you please clarify what you mean by "adding the covenant"? I'll quote what I wrote above, which directly addresses what seems to be your concern, if I understood correctly:

  Note that I'm not suggesting adding yet another guideline document to our project; I too would object to that, especially since the current texts have already proven to be (ironically! 😄) partially TL;DR in some instances. What I suggested was to simply add explicit signals that our existing adherence to the principles of inclusive and respectful interaction indeed is meant to also cover the situations the covenant focuses on — by making the language of point 2 of the GOVERNACE.md document more explicit (including a link to the covenant) and adding a badge to the README (or CONTRIBUTING.md, if that's more palatable). That's all.

• This is exactly the kind of stuff I would not want to deal with.

  I totally agree that we don't need to accommodate radical positions. But adopting the covenant or not makes no difference in how we handle such situations. We have had people refuse to continue engaging in PRs because they felt the review process was too cumbersome (and to be honest, it sometimes is). Did we go after them and beg them to return? No, we tried our best to explain, integrated the changes using alternative means, and tried to learn from the experience and become more proficient at detecting signs of fatigue early on, to prevent such situations from happening in the future. And yes, we adjusted our guidelines to help maintainers keep that in mind. The same happened with heated discussions about whether to adopt the CLA, and whether to have a single client managed by us or an ecosystem, and so on. All of these are examples of situations where people strongly disagreed, some even abandoned the project because of it, but overall the community handled it with mutual respect and the project moved on in a constructive manner. So I know for a fact (and am proud to say it!) that we can handle conflict constructively and humanely. A badge and link should bear little influence in that :)

[principis]

@principis can you please clarify what you mean by "adding the covenant"? I'll quote what I wrote above, which directly addresses what seems to be your concern, if I understood correctly:

Yes, I understood what you said. :) (I shouldn't have written that comment so late at night.) The part about "Adding the covenant" was not related to what you said, the first part, making part 2 more explicit, is. I mean by adding the covenant, adopting it as a code of conduct and enforcing it.

I don't think there's anything wrong with the text itself, I agree with most of it. I don't really know what the benefit is by linking it in part 2. If we do that with the thought of "this is a more formal explicit document that expresses our values but we don't think it's necessary for us to add it" or something like that (see quote below), I think that is ok. As said before, I don't know if adding the badge while not adding the covenant itself is an option.

informal (but truthful) signals that we as a community make explicit to the wider open source ecosystem that we aim to implement the covenant's principles (as we already do).

So to rephrase my messy opinion, I'm against adopting the covenant as a code of conduct (and thus enforcing it) because of everything said before, but I agree with making part 2 more explicit and maybe linking to the covenant in a way that doesn't make us bound to it.

(I'm sorry if I annoyingly repeated opinions, already addressed concerns or seem to change my opinion)

[sbrl]

Wow, well this blew up while I was asleep.

We've got quite a few guideline documents already, so from a reducing initial barriers point of view, I'd be cautious of adopting this code of conduct. However, that's not to say it's a bad idea. Personally, I'd prefer to edit our existing GOVERNANCE document to add some of the things we missed, rather than adopt an external document (which I feel would be both confusing for new contributors and somewhat redundant).

After all, one of the key principles of tldr-pages is to make it easy for new contributors to get started and open their first pull request.

If this conduct document is as politically controversial as it sounds like it is, this would have the added benefit of us not subscribing to 1 school of thought or the other, and remaining somewhat 'neutral' I think. Not being bound to a politically controversial document that's liable to be updated underneath our feet sounds like a good idea in my mind.

Ninja Edit: @tapaswenipathak: It's probably worth mentioning that it's not just a specific document or project that can tackle issues such as the ones this document under discussion does. Anyone can make changes to their pre-existing system to tackle such issues without using that document should they choose.

[tapaswenipathak]

Hey folks: A doc describing the principles and values you would want the community should follow would work for me. Happy writing, thanks. I would love reading the final document.

[waldyrious]

Thanks for the clarification, @principis. I think we can reach a consensus here, then:

maybe linking to the covenant in a way that doesn't make us bound to it.

IMO linking to the document from GOVERNANCE.md and adding a badge (plus our documented history, as @agnivade helpfully pointed out, of care for a friendly environment and civil discussion when faced with disagreements) is sufficient to demonstrate to prospective contributors than we're aware of the issues the covenant highlights, and prepared to handle them with respect and empathy should they occur, while not making us (legally or otherwise) bound to implement the specific process described in it (which I don't think would be an issue anyway, but still).

If that means we would be able to appease concerns both from new contributors (that we may not be serious in adhering to the principles of the covenant) and from existing contributors (that we would become vulnerable to targeted attacks hinging on our adoption of the covenant), then, as @agnivade said, it could be a win-win situation.

Btw, thanks @sbrl for explaining in better words my concerns with making the contribution documentation too extensive.

[mebeim]

So I guess that at this point the question is: @waldyrious could you provide a concrete example of what you would add to point 2 of GOVERNANCE.md and which badge you would add to the README.md?

Are you talking about this badge?

Because if so, I don't really think it would make much sense to add the badge and not the CCCoC document itself. That's like distributing software without a license and saying "yeah I use MIT by the way you can go look it up". In other words, the only two options which make sense IMHO are either both (badge + document) or none, and I already stated my opinion on why I would prefer the latter.

[waldyrious]

Yes, that would be the badge (or some more compact variation perhaps, based on shields.io).

Again, I think it's more relevant that we apply the principles in practice than have a piece of "paper" saying we do. Besides, even in licensing, it's possible to be compliant by making an unambiguous reference to the license without duplicating the entire text in the project (e.g. CC licenses work like this, and SPDX identifiers serve precisely this purpose). Distributing entire copies of a license text comes from a time where software was often distributed in physical media; nowadays it's quite acceptable to provide links, to not include a license text in every source file, etc.

I don't think anyone would consider lack of strict adherence to a recommended practice (in this case, adding the full text of the covenant to a repo as opposed to the badge and a link) would mean we're automatically disqualified as "true" adopters of its principles, especially since we do, in practice, implement them. If anyone would argue that, I'd say that's a bad faith position which we shouldn't have to accommodate. I see no reason to be all-or-nothing on this.

As for the changed text to GOVERNANCE.md, I'll submit a proposal later today, but it should be minimal changes, really.

[mebeim]

The line is really blurry though. If there's a badge on our README.md people will of curse think we are adopting CCCoC. So are we? Or do we only agree about the same principles (which I would say it's basically just common sense) without actually adopting it? That's what I was trying to understand. You are suggesting that we adopt it, right @waldyrious?

I would also like to hear @pxgamer's opinion on this issue.

[waldyrious]

@mebeim it depends on what you mean by "adopt it". To me, that means ensuring that our community's processes are compatible with the goals of the document (which they are, so no change here), and being willing to roughly follow the ways of handling issues that it suggests: privately responding to any complaints, raising the issue with the contributors that are mentioned as the source of the aggression, and taking action to curtail any abusive behavior if it persists. Again, none of this is new; we'll just be signaling to prospective contributors that we're aware of these issues and committed to handle them should they occur (which, again, I don't see happening anytime soon).

If you're concerned that adopting the covenant means we'll have to follow the conflict resolution procedures to the letter, exactly as described in the document, let me state explicitly that I do not support that, nor I believe it's required to claim we adopt it. That would be giving more importance to the letter of the law than to its spirit! Nuance is key to empathically handle conflict; even the best-intentioned policies can be abused if followed blindly and unflexibly.

[mebeim]

@waldyrious thank you for explaining. By "adopting it" I mean agreeing to and following all the terms of the document. So as I understand you're not suggesting to adopt it (using the definition I just gave). This is the reason why I find it questionable to add the badge, because IMHO that would make users think we do adopt it. Don't you think so?

[sbrl]

I would not be happy with a badge like that, as I think it would be misleading (also, it looks blurry to me?). As @waldyrious says, we can indeed create our own badges with shields.io:

URL of image: https://img.shields.io/badge/some%20text-example-ff69b4

Ninja edit: If we use shields.io, it will look more consistent with other badges.

I'm not sure what it should say myself. I'd question though whether the badge is really something we need? I'm all for updating the governance document, but do we really need to advertise this fact? I'd rather not draw attention to it if we don't need to - as we've mentioned earlier in this discussion our community is pretty welcoming and open already (or at least I'd like to think so). If we did have a problem, then advertising it might be the way to go. But as it stands I don't think we do have an issue here, so adding a badge doesn't seem like would serve much purpose.

[mttbernardini]

Hi everyone, I wanna give just a little clarification about the issue of "adopting" the CCCoC (following @mebeim definition of "adopting").

Besides, even in licensing, it's possible to be compliant by making an unambiguous reference to the license without duplicating the entire text in the project

@waldyrious I'm not quite sure about this statement. Take some random license, e.g. the MIT License, it clearly states that «The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.», so only giving a link to the license would NOT be a valid option to "adopt" it.

I think the issue addressed here is analogous to the following scenario: imagine a project writing a license document which resembles the MIT License (but with different phrasing and statements) and also provides a link to it. That doesn't automatically mean the project adopts the MIT License, because of the requirement above. It merely means that it follows a custom license which is somewhat "compatible" with the MIT License, in the same way there are compatibility tables between different licenses. This way, saying that the project follows the "MIT License" or including a license badge of the "MIT License" would be wrong, since a license is a legally binding document and even apparent slighly different phrasings could have totally different implications (I'm not a legal expert here, so I can't tell exaclty, to my eyes some licenses say basically "the same things", but evidently they're different, otherwise they wouldn't need to have different names, would they? or having compatibility tables, for that matter).

In the same way, for this reason, I agree with @mebeim saying that including a CCCoC badge without really "adopting" it would be really wrong, especially if a CoC is a legally binding document too (as @mebeim suggests). Your own custom CoC would only be somewhat "compatible" with the CCCoC (indeed you could state this instead) and that's all.

I hope this helps ;)

[mttbernardini]

Maybe, if you want, you can rename the GOVERNANCE.md document (which I identify as the CoC of this project basically, is my assumption correct?) to CODE_OF_CONDUCT.md (which is the suggested conventional name by GitHub).

This way it would appear to the "community" tab here in GitHub and maybe it would be a more familiar name for new coming contributors, the same way LICENSE.md is.

What do you think?

[owenvoke]

Sorry for not really being active in this discussion, I have been following along though. In short... I'm fine with whatever we decide on. 👍 However, I feel that a welcoming attitude is better shown through actions, rather than through a document. 🤔

I feel that adding the CCCoC doesn't have much benefit over the GOVERNANCE file, as this covers the basics of how we interact with contributors (perhaps it could have a little more detail and tweaks as mentioned), but I feel it might be unnecessary to follow the CCCoC as most of it is common sense. The CCCoC also doesn't seem to have any real effects on behaviour from what I've seen in the past. 🤔

Regarding the badge, I also agree that it would be kind of misleading to include the badge without actually using the CCCoC in the repository. Plus I'm not sure an additional badge adds much to the project.

[waldyrious]

I am aware that some licenses do require full quotation of the license text; I also am aware that others (like Creative Commons licenses) don't. I just meant to exemplify that including the text isn't universal principle of license application that somehow grants them legal validity.

I stand by my position that actually following the best practices recommended by the covenant (and making it unambiguous to others that we do, by means of a badge, a note of adherence with a link, or whatever else) means more than adding a document to our repository just so we can claim strict adherence to the covenant -- even OP @tapaswenipathak has said as much. And conversely, I believe that not adding the document could not negate the fact that we actually comply with it. Besides, the covenant certainly isn't a legally binding document, as @mebeim himself clarified. So in my view, insisting on prodecural/bureaucratic compliance (rather than real compliance by means of living up the principles as part of our project's culture) would buy us little value, and what's more, would do it at the expense of significant churn, which we can easily avoid by focusing on the spirit, rather than the letter, of the covenant -- with no downside to anyone involved!

If you prefer calling the above something other than "adopting the covenant", fine -- we can use whatever other word you're comfortable with. If you think we're somehow not allowed to use the badge unless we strictly follow the exact procedures described in the document -- well, I disagree, as I stated above, and would find it most unfortunate if over-zealous self-policing prevented us from signaling our goodwill and awareness to the people who recognize the covenant and take reassurance in a project's adherence to it. IMO that would be a disservice to the community for no gain.

As for renaming GOVERNANCE.md: note that only points 1 and 2 are recommendations for how to interact in a positive and constructive manner; points 3, 4 and 5 focus more on decision-making and transparency, which is less about conduct and more about, well, project governance. The latter (collective behavior) subsumes the former (individual behavior), but not the other way around. Therefore, I would object to renaming the document simply to make it more visible, since that would also make it more ambiguous.

To finish, let me just reiterate that I have no personal interest in us adding the covenant; I just felt it could be an easy way to provide additional assurances to contributors, without requiring any change in our culture, so why not? I really don't understand why there's such resistance to it, especially when nobody, IIUC, is advocating adding the full text of the covenant to our repo. With this said, I will stand back for a bit to let others have a say, as I've been way too verbose on this discussion already! :smile:

[mebeim]

Besides, the covenant certainly isn't a legally binding document, as @mebeim himself clarified.

I said the exact opposite. It is a legally binding document (of course only if one decides to bind theirself to it by incorporating it in the project, which is not what you're suggesting).

If you think we're somehow not allowed to use the badge unless we strictly follow the exact procedures described in the document -- well, I disagree

I don't think that. I just think it would be confusing and unnecessary. Besides, as @sbrl pointed out, what should such a badge even say?

I would object to renaming the document simply to make it more visible

Agree, renaming wouldn't make much sense. Splitting would make more sense, if anything. I see most of the people here don't want yet another distinct document around, and I agree with that too, so it's fine either way for me.

[mttbernardini]

If you think we're somehow not allowed to use the badge unless we strictly follow the exact procedures described in the document -- well, I disagree

IMHO including a badge without actually fully complying with the CCCoC would only be misleading, because people would expect things which are pretty specific to it, but are not applied here (e.g. the way enforcement is applied in the CCCoC). It would give an unnecessary false signal of "strict adherence" rather than "inspiration".

What I'm trying to say is that is not the CCCoC badge (nor any mention to CCCoC) that would make this project attractive to new people (indeed GitHub also suggests the Citizen CoC as a template, so why not mentioning it for that matter, or the others various CoCs that exist?), but the mere fact that this project has some sort of inclusive CoC in the first place, whichever it is (and, of course, putting those actions in practice and not just having a text document). I think just having a standard CODE_OF_CONDUCT.md file (whichever file is suited for this, even a new one) is more than enough to make this thing clear.

PS: I'm not againts the CCCoC, my only interest here is just giving my personal and external point of view on the matter (as I'm not a collaborator) hoping that it might be helpful, so take it for what it is, all the final decisions are up to you others ;)

[agnivade]

Guys, let's just expand GOVERNANCE.md to add some more points from the CCCoC, especially the contact email address for reporting abuse. It is something we already have but it's not publicized. No need to add any reference to the CCCoC.

I think all of us have put forth our points and this is something we all can agree on.

I would leave it to @waldyrious to take the lead on making the changes.

Let this be another exemplary example of listening to both sides of a discussion and coming to a resolution. :)

[agnivade]

@waldyrious - Wondering if you can take a look at this whenever you get a chance? Perhaps it slipped through the cracks.

[waldyrious]

Yeah, let's wrap this up. I'm thinking it would be good to add a sentence at the end of point 3 of GOVERNANCE.md, "All communications are public", mentioning a way to privately report abusive behavior. Does that seem adequate to you all?

We could use the mailing list we initially created for the Season of Docs program, tldr-pages@googlegroups.com, but I was wondering if we might suggest privately messaging one of the org owners on Gitter as an alternative (either instead of the email, or in addition to it). Thoughts?

[mebeim]

@waldyrious agree. Between the two, I like the mailing list idea better since that would be more transparent for us internally.

[agnivade]

Agree. Personally, I prefer mail though. I don't open gitter that frequently.

[owenvoke]

Just interested, is there a way to check if I'm in the mailing list? 🤔 I also don't get notifications from Gitter due to a bug that's been around for ages (see Gitter docs).

[waldyrious]

Good point, @mebeim, I agree that a mailing list is better in that respect. 👍 And given @agnivade's preference, and the notifications issue @owenvoke raised, I'd say it's best if we move ahead with that approach, then.

Just interested, is there a way to check if I'm in the mailing list?

The list of members can be seen here (and you're in there), but now that you mention that, it reminds me: we probably should include a step for adding people to this list in the instructions for transitioning people to the owner role. 🤔

[sbrl]

I keep Gitter open as a persistent tab, so that works better for me personally. Perhaps we should add both methods, just in case.

[waldyrious]

Alright, thanks for the input! I'll make a PR to edit GOVERNANCE.md as soon as #4516 is merged.

[bl-ue]

@waldyrious #4516 was merged 2 months ago, could you do this now?

[bl-ue]

Hey @waldyrious! Will you please make the edit to GOVERNANCE.md so we can close this issue?

[sbrl]

@bl-ue 1 reminder is enough :-) @ waldyrious is quite busy - there's no rush to close this issue :-)

Generally speaking tldr-pages has a number of longer-running tracking issues open about various things, since none of us have ever met in person and here (and Gitter) are the only places we have to communicate. This is one of them :-)

[bl-ue]

Okay @sbrl!! Apologies for being so persistent :)

[sbrl]

Ah, no worries :-)