Skip to content
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
This repository was archived by the owner on Apr 22, 2023. It is now read-only.

1 Code of Conduct for everything?聽#7

Closed

Description

@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

Activity

  1. hackygolucky commented on Jan 14, 2017

    @hackygolucky
    Contributor

    @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?

  2. jasnell commented on Jan 15, 2017

    @jasnell
    Member

    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.

  3. williamkapke commented on Jan 15, 2017

    @williamkapke
    ContributorAuthor

    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.

  4. dshaw commented on Jan 16, 2017

    @dshaw
    Contributor

    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.

  5. nebrius commented on Jan 17, 2017

    @nebrius
    Contributor

    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?

  6. jasnell commented on Jan 17, 2017

    @jasnell
    Member

    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.

  7. ashleygwilliams commented on Mar 8, 2017

    @ashleygwilliams
    Contributor

    @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.

  8. jasnell commented on Mar 8, 2017

    @jasnell
    Member

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

  9. nebrius commented on Mar 8, 2017

    @nebrius
    Contributor

    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?

  10. ashleygwilliams commented on Mar 8, 2017

    @ashleygwilliams
    Contributor

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

  11. hackygolucky commented on Mar 9, 2017

    @hackygolucky
    Contributor

    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...

  12. nebrius commented on Mar 9, 2017

    @nebrius
    Contributor

    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 :)

  13. mhdawson commented on Mar 9, 2017

    @mhdawson
    Member

    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.

  14. williamkapke commented on Mar 9, 2017

    @williamkapke
    ContributorAuthor

    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.

  15. jasnell commented on Mar 10, 2017

    @jasnell
    Member

    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)

  16. williamkapke commented on Mar 10, 2017

    @williamkapke
    ContributorAuthor

    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?

  17. jasnell commented on Mar 10, 2017

    @jasnell
    Member

    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.

  18. jasnell commented on Mar 10, 2017

    @jasnell
    Member

    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.

  19. williamkapke commented on Mar 10, 2017

    @williamkapke
    ContributorAuthor

    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.

  20. ashleygwilliams commented on Mar 10, 2017

    @ashleygwilliams
    Contributor

    @jasnell thoughts on me making it an npm package?

  21. jasnell commented on Mar 10, 2017

    @jasnell
    Member

    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.

  22. ashleygwilliams commented on Mar 10, 2017

    @ashleygwilliams
    Contributor

    no rush ;)

  23. gibfahn commented on Mar 10, 2017

    @gibfahn
    Member

    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?

  24. ashleygwilliams commented on Mar 10, 2017

    @ashleygwilliams
    Contributor

    @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 馃槄

  25. nebrius commented on Mar 31, 2017

    @nebrius
    Contributor
  26. jasnell commented on May 18, 2017

    @jasnell
    Member

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

  27. nebrius commented on Jun 7, 2017

    @nebrius
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions