1 Code of Conduct for everything?

[williamkapke]

I noticed that some projects/repos/WGs have copied the full text of a version of the CoC. IF we want to make changes/additions/revisions - it makes it... hard 👎

Can/Should we have just the 1 copy of the CoC?

The primary copy

https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md

Copies I found

(I didn't diff them to see if they are identical or not)
https://github.com/nodejs/community-committee/blob/master/CODE_OF_CONDUCT.MD
https://github.com/nodejs/community-committee/blob/master/COLLABORATOR_GUIDE.MD

https://github.com/nodejs/post-mortem/blob/master/CONTRIBUTING.md
https://github.com/nodejs/benchmarking/blob/master/CONTRIBUTING.md
https://github.com/nodejs/http2/blob/master/CODE_OF_CONDUCT.md
https://github.com/nodejs/evangelism/blob/master/CONTRIBUTING.md
https://github.com/nodejs/Intl/blob/master/CONTRIBUTING-draft.md
https://github.com/nodejs/nodejs-uk/blob/master/CONTRIBUTING.md
https://github.com/nodejs/nodejs.org/blob/master/COLLABORATOR_GUIDE.md
https://github.com/nodejs/docs/blob/master/CONTRIBUTING.md
https://github.com/nodejs/nodejs-hu/blob/master/content/en/working-groups.md

These are special cases:

https://github.com/nodejs/node-chakracore/blob/master/CODE_OF_CONDUCT.md
https://github.com/nodejs/iojs.org/blob/master/CONTRIBUTING.md
https://github.com/nodejs/inclusivity/blob/master/CODE_OF_CONDUCT.md
https://github.com/nodejs/node-convergence-archive/blob/master/CONTRIBUTING.md
https://github.com/nodejs/docker-node/blob/master/GOVERNANCE.md
https://github.com/nodejs/docker-iojs/blob/master/GOVERNANCE.md

[hackygolucky]

@williamkapke Yes, very much so. This was something that was brought up in the meeting about forming the CC as well, that it's really important that everyone works together regardless of the WG or org they are part of to try to have a single CoC as a united community.

The challenge I have is that I think it -does- need to be visible and available to read fully without having to click somewhere. Humans are lazy :) I'm feeling very uncreative at the moment but is there an easy way to do that?

[jasnell]

It would definitely be ideal for there to be only one copy... but like @hackygolucky, I'm rather unsure how to accomplish that while retaining visibility.

[williamkapke]

Markdown is very limited in this aspect. The closest thing we would probably be able to do to keep the text in the README- but be able to update it else where is...🤔 ... an image of the text. 🙄

Thumbs down acceptable here lol.

[dshaw]

One other approach could be to place a link in all copies to the canonical version and request that all comments, suggestions, and pull requests be made to that version.

[nebrius]

hmmmm...what about coming up with a short version/long version like the GPL license does? Ideally the short version wouldn't change much, but would link to the longer version?

[jasnell]

I've been considering the possibility that the code of conduct should live in it's own repo (e.g. nodejs/code-of-conduct) and that each of the individual repositories should just link to it prominently in their README and contribution guides.

[ashleygwilliams]

@jasnell i think we could share this p well by making a npm package for the node CoC. it can be added as a dependency to every project. this keeps it in a place we can consider a single source of truth.. also... versioning!! thoughts, ya'll? happy to make that today if we are into it.

[jasnell]

That's a solid posibility. I'll bring up the idea of separating out the CoC on this week's TSC call.

[nebrius]

Interesting idea @ashleygwilliams, I like the versioning aspect to it! Do you have any thoughts on how this would be surfaced in README and/or CONTRIBUTING for people who never run npm install?

[ashleygwilliams]

i think we can also just link to the github repo @nebrius

[hackygolucky]

Update: TSC is going to move the CoC into its own repo so there is one that we can all link to, and communicate this happening with the various working groups who each have their own CoC up.

@williamkapke @jasnell I have a question about governance with the CoC. It was mentioned that current TSC governance allows for each WG to have its own CoC. Does that allow for a CoC to be less lax than the official Node.js CoC? I found this really interesting because it seems like a weird legal gray water.

I may have completely misunderstood the comment...

[nebrius]

I could be wrong, but I seem to recall that any alternative CoC needs to "backwards compatible," so to speak, and thus can't be more lax, however I'm not actually able to find that documented anywhere.

Regardless, I do think that should be a requirement. If nothing else, it makes moderation a lot easier because the project wide moderation team doesn't need to learn the ins and outs of the different CoCs (implying that anything extra added needs to be enforced by that group, not the moderation team, which I also think is a good idea).

Also IIRC, the old Inclusivity WG is the only group with a CoC that is practically different than the main CoC. Everyone else copy-pasted from the WG template, and so any differences are due to bit rot, not intentional effort. My memory could be wrong on this though :)

[mhdawson]

For all of the WG I'm involved in there was never a conscious decision to change the CoC from the default. My understanding is that per the existing rules WG's are free to use whatever CoC they feel is appropriate, but I assume @williamkapke will correct us if its spelled out anywhere that that is not the case.

[williamkapke]

Nope- no corrections from me! Working groups have full autonomy to do whatever they like (until they get revoked). So much so- that they could chose to make it so their processes violate that master CoC referenced above. Fortunately, we have a really awesome community and that doesn't even seem like a remote possibility of ever happening. 😄

It should also be noted that, currently, creating Teams is favored more than Working Groups. Autonomy is not granted to Teams (aka Discussion Groups) by anything we have documented. In these cases, they should be an extension of the group they report to and should follow that group's rules.

Personally: I'm in favor of having some bare minimum set of requirements instead of "absolute autonomy" but ... maybe that's a slippery slope. I've also advocated for just having it be a "strongly suggested" list since most(all?) current groups seem want to just doing things like the other groups.

[jasnell]

Based on the TSC discussion today, there were no objections to moving the Node.js core Code of Conduct into a separate repository for easier reuse. The TSC would retain responsibility for managing the content of the CoC. Working Groups would retain the fulll autonomy they have today to choose the CoC that works for them with the core CoC being the default (in other words, zero changes from the current situation).

The next step is for me to set up the CoC repository and open the PRs that will move the CoC in (which I will do either later this evening or tomorrow)

[williamkapke]

I would rather just leave it in the nodejs/node repo and link to it there. Maybe move it to TSC if anything. I'd just rather not have a new repo only for that one file. We'd need to define the new repo in the TSC scope and inform the board.

Can we solicit more feedback on the location first?

[jasnell]

Listing the repo in the TSC scope is easy. I'm not seeing why we need to inform the board of anything but that's easy also.

[jasnell]

Essentially, the objection seems to be one based on process for process sake. We can certainly leave the CoC where it's at currently and simply not change anything if that's the easiest thing to do and it's what everyone wants, but the objection should not be based on a largely artificial process concern. There are either benefits to having the CoC in a separate repo, or there are not.

[williamkapke]

I should have said "Additionally, We'd need to ... blah blah"

It was meant to inform of additional process- not at all the root of my objection. Sorry for the confusion.

[ashleygwilliams]

@jasnell thoughts on me making it an npm package?

[jasnell]

Assuming there are no objections to setting up the separate repo, that should be fine. We'd just need a PR to set it up. Gimme a day to get the ball rolling.

[ashleygwilliams]

no rush ;)

[gibfahn]

thoughts on me making it an npm package?

@ashleygwilliams interesting idea, how would you expect it to be used as an npm package? Would projects declare it as a dependency?

[ashleygwilliams]

@gibfahn yeah i would see projects declaring it as a dep. also it's a good way to keep track of versions, cuz... versioning! heh 😅

[nebrius]

FYI: nodejs/TSC#224 (comment)

[jasnell]

Given that this has already been discussed by the tsc, I'm going to pull the tsc-agenda label off.

[nebrius]

I'm going to go ahead and close this issue. The CoC has been moved, and we have #34 to track updating the references to it. If I missed something, please feel free to reopen.