You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
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 馃憥
@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?
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.
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. 馃檮
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.
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?
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.
Reacted by Tierney Cyren, Nikita Skovoroda, Bryan Hughes, Rachel White, Tracy, ashley williams and Felipe Torres (fforres)
@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.
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?
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...
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 :)
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.
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.
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)
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?
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.
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.
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.
Activity
hackygolucky commentedon Jan 14, 2017
@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 commentedon Jan 15, 2017
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 commentedon Jan 15, 2017
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 commentedon Jan 16, 2017
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 commentedon Jan 17, 2017
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 commentedon Jan 17, 2017
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 commentedon Mar 8, 2017
@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 commentedon Mar 8, 2017
That's a solid posibility. I'll bring up the idea of separating out the CoC on this week's TSC call.
nebrius commentedon Mar 8, 2017
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 commentedon Mar 8, 2017
i think we can also just link to the github repo @nebrius
hackygolucky commentedon Mar 9, 2017
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 commentedon Mar 9, 2017
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 commentedon Mar 9, 2017
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 commentedon Mar 9, 2017
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 commentedon Mar 10, 2017
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 commentedon Mar 10, 2017
I would rather just leave it in the
nodejs/noderepo 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 commentedon Mar 10, 2017
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 commentedon Mar 10, 2017
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 commentedon Mar 10, 2017
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 commentedon Mar 10, 2017
@jasnell thoughts on me making it an npm package?
jasnell commentedon Mar 10, 2017
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 commentedon Mar 10, 2017
no rush ;)
gibfahn commentedon Mar 10, 2017
@ashleygwilliams interesting idea, how would you expect it to be used as an npm package? Would projects declare it as a dependency?
ashleygwilliams commentedon Mar 10, 2017
@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 commentedon Mar 31, 2017
FYI: nodejs/TSC#224 (comment)
jasnell commentedon May 18, 2017
Given that this has already been discussed by the tsc, I'm going to pull the tsc-agenda label off.
nebrius commentedon Jun 7, 2017
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.