Code of Conduct.

[mikeal]

Governance and contribution policy are now in #13

Code of Conduct is now in #14

I was about to comment on the new threads about core governance when I realized that all of them presume some knowledge of the structure we've adopted and have been using for some time in Node Forward.

Without discussing and being able to link to some kind of ongoing documentation I don't think the conversation threads will be very fruitful so I've gone ahead and written them up in this pull request.

They are adapted from Node Forward's fork where they are sections in the CONTRIBUTING file. Here I've put them in to their own files for clearer separation. All direct references to Node Forward have been removed so that this can be adopted by any project without confusion.

The premise is simple: the project employs a simple governance structure that can be the "final word" on contentious issues and, most importantly, owns the contribution policy. The contribution policy is intended to be somewhat fluid and adapt over time to the needs of the project. The current one is geared heavily towards growing the contributor base of the project because that's the biggest problem. You can imagine that after the project grows a large cohort of contributors this policy would change to adapt the challenges of distributing work among a larger contributor base.

This separation between contributor and TC member is a necessary one. Liberalizing the contribution policy has been an effective tool at growing new contributors in Node Forward and in other projects that have been employing similar policies for some time. Of course, contributors who spend a fair amount of time in the project and want to take on additional responsibilities will find themselves on the TC but the direct correlation of commit rights to being part of a sometimes boring and bureaucratic process of managing the project at a higher level is an unnecessary barrier to growing contributors.

[othiym23]

The Code of Conduct is good, although I would like to see more specific language about enforcement, scope that is governed by the CoC, and who to contact with concerns or questions. I understand the need for wiggle room, but if you look at npm's CoC you'll see that it leaves room for interpretation while making pretty clear the who, what, and how of using it day to day.

For significant changes wait a full 48 hours (72 hours if it spans a weekend) before merging so that active contributors who are distributed throughout the world have a chance to weigh in.

If the TC themselves came up with this idea of time limits, then I'm fine with it, but that's a pretty short timeframe given how busy everyone is and how widely distributed the TC is. Having a consistent release cadence or a regularly scheduled, standing triage meeting are other ways to help people feel like their issues aren't being dropped on the floor.

TC members nominate contributors to be added to the TC which the TC will vote on. They can nominate any individual during any meeting.

I thought @danese's discussion of how Apache SF voting works with regard to personnel changes to be compelling, and would like to see others discuss whether they think that's applicable to Node. Having a transparent path to and process for gaining membership of the TC is critical to renewing the project.

The TC can change its governance model if they deem it necessary. The current governance rules are:

• Consensus Seeking
• Motions with voting when consensus cannot be reached.
• Quorum of 2/3 (66%), simple definite majority wins.
• No more than 1/3 (34%) of the TC membership can be affiliated with the same employer.

I think this is a fantastic process.

I also think the current TC membership is a good start, although I am surprised to not see @chrisdickinson or @misterdjules on that list, as both have been very active contributors to Node recently.

[max-mapper]

While we're at it can we add a rule about making it okay to ban anonymous trolls from GitHub issues?

[othiym23]

@gramergrater I disagree; if Node had had a Code of Conduct in place from the beginning, it would have eliminated a lot of melodrama, and would have attracted a broader base of contributors. Creating a cordial, harrassment-free collaborative environment is crucial to maintaining a healthy OSS project.

[mikeal]

@gramergrater the CoC is long overdue and is part of the CONTRIBUTING documentation in Node Forward. Accepting the CoC is part of contributing, if you don't accept the CoC then you actually can't be an active contributor :)

[mikeal]

although I would like to see more specific language about enforcement

Agreed. There isn't a huge amount of prior art for project based CoC's so we're sort of on our own to come up with this language. Would you mind drafting it @othiym23?

pretty short timeframe given how busy everyone is and how widely distributed the TC is

most patches do not require the full TC to approve. it's expected that contributors are watching for PR's in areas they tend to understand and manage and this time frame (which originally was shorter and was actually extended at the request of the TC) is there to ensure they have a chance to chime in one the ones they care about.

I am surprised to not see @chrisdickinson or @misterdjules on that list

The current list is adapted from the historic committer list. Note that under the new contribution policy many people will full commit access are not on the TC. It is my understanding that @chrisdickinson and @misterdjules fall under some sort of "apprentice" designation which may or may not have write access to the repository (I'm not sure and the documentation around this designation is unclear). Regardless, under the new contribution policy they would certainly have commit access, and there are a few other people in Node Forward who have also gained commit access but are not on the TC.

I thought @danese's discussion of how Apache SF voting works with regard to personnel changes to be compelling

I actually disagree but I've address that at length here https://github.com/joyent/nodejs-advisory-board/issues/6#issuecomment-63017529

Would love to get more of your input on that particular point in that thread.

[othiym23]

a CoC itself doesn't make a "harrassment-free collaborative environment"

I agree. This is why I'm asking for additional clarity around the Node CoC – it should never be surprising when decisions are made about project governance due to the CoC, and there should be a low-intensity / low-heat way to resolve conflicts related to the CoC before they turn into actual problems.

I'm concerned both about growing the Node community and keeping the community we already have as enjoyable and healthy as possible, and in my experience (and in my discussions with other members of the community), codes of conduct (and their absence) have played an important role.

[othiym23]

Would you mind drafting it @othiym23?

I can take a swing at adapting what we've got for npm for Node, and maybe if we have some time and money before the end of the year we can have @ashedryden take a look over it.

most patches do not require the full TC to approve. it's expected that contributors are watching for PR's in areas they tend to understand and manage and this time frame (which originally was shorter and was actually extended at the request of the TC) is there to ensure they have a chance to chime in one the ones they care about.

I am probably defensive about this because I am so far behind on my work for npm, but I do think the idea of having explicit time windows around this seems a little arbitrary and potentially limiting. Most of the time, if it's something that @indutny or @trevnorris know about, they'll get to it almost immediately, and it's very rare that things get neglected unless they're genuinely weird or complicated. This isn't a huge sticking point to me, but it did stick out as possibly unnecessary.

[mikeal]

@gramergrater if you disagree with the language or enforcement procedures (or lack there of) in the CoC then please spell them out in a constructive way we can use to improve the document. While you may feel that simply having it is improper that point is moot since it was already adopted by the Node Forward TC who did find it relevant and is a part of the overall governance and contribution strategy which is being presented here. I also think you miss-understood my statement, the CoC covers the kind of conduct that is not allowed, and that is relevant to contributing. For instance, pull requests that contain sexist statements in comments or commit logs would not be accepted. That is what I mean by "if you can't accept the CoC you can't contribute." If your behavior falls outside of the realm of acceptable conduct you won't be allowed to contribute, plain and simple, and this is what lays that out. You may have internalized these principals and would never even consider engaging in this kind of conduct, but people from underrepresented groups have an aversion to participating in projects that don't have clear conduct guidelines.

[mikeal]

@othiym23 I'm confused. Is the issue that you think the window is not long enough or that it is too long and will make people feel like they are being ignored? Perhaps we should pull in @rvagg as levelup has had a 24 hour policy for some time (and in reality it's more like 72 hours at least).

[othiym23]

Is the issue that you think the window is not long enough or that it is too long and will make people feel like they are being ignored?

I'm sorry, I think my response was conflating my understanding of what problem the window is intended to solve with my feelings about it. I think putting a limit on turnaround time either way is a little weird, but mostly I'm saying the window probably isn't long enough for the kind of exceptional patches that would justify it being there in the first place.

Maybe it's useful to say, "don't complain until x days have elapsed", but I doubt it. On the other hand, sometimes a patch will look like an easy merge to the submitter and won't be (maybe it explodes on Linux or Windows, maybe it causes non-deterministic test failures), and to avoid having it turn into a time suck for a team member, it'll be necessary to shelve working on it for a while. I see examples of this in Node all the time.

[mikeal]

@othiym23 I think I get what you're saying now. The window isn't intended to be a ticking clock on how long the review process is likely to take. Big changes could be talked about for weeks. It's more like "If nobody says they have an issue with this patch in X amount of time I can merge it." You have to keep in mind that this is a much more liberal contribution policy and it is expected that far more people will have write access so this rule is there as a guideline for how long you need to wait for input. If you get negative input you'll need to resolve that before landing, regardless of any initial window for input.

This is all to say "we should make the language in the contribution policy much clearer." :)

[gramergrater]

@mikeal alright, that makes sense except for the part about "underrepresented groups". That's a weasel-worded phrase and from a pragmatic standpoint, I wonder if the Venn diagram of those groups and contributors shows overlap. This might seem self-defeating as you stated they have an aversion to projects without a CoC, but it helps to put into perspective why the CoC was written the way it is.

Thanks for sharing your thoughts, it is good to have this debate and get input from the community imho.

Next day edit: My apologies to those who feel this post is unsettling or even offensive. Your comments on Twitter have not gone unnoticed. However, I can't respond on other social networks so I'm afraid that this humble apology will have to do.

[mikeal]

@gramergrater if it helps at all I know of one woman who would already be an active contributor but has held off because of prior conduct issues and the fact that, even after those issues happened, the project didn't adopt a CoC. So yes, there are contributors who would be contributing and aren't because we don't have this.

[mikeal]

@gramergrater we can speculate all day about how typical her experience is but at the end of the day I don't get to decide what makes women feel safe in the project and her experience is far more relevant than mine or other men's experiences and their opinions or speculations about women's experiences.

I don't find your Westboro strawman compelling at all. The Code of Conduct governs conduct not beliefs. It sets the foundation for a safe space where people who may have dramatically opposing personal beliefs and backgrounds to contribute without fear that they will be discriminated against or made to feel uncomfortable or unwelcome within the context of the project and conduct within that project.

[gramergrater]

@mikeal of course those experience aren't relevant, they are outside of the scope of the group (that is, female contributors). What is relevant, however, is whether there's one person crying foul or if the present community is actively engaging in gender discrimination (or other kinds thereof). That falls under conduct, right? To me, it doesn't matter what the discrimination is based upon. That's why I mentioned westboro. Sorry if I worded this too confusingly, I think we're mostly on the same page here.

[andrewlow]

+1

Making the code (and community) inclusive and diverse should be part of the DNA of this project. This should cover individuals and corporations alike.

[Fishrock123]

+1 for CoCs and openly defined governance models.

why we need a CoC: https://medium.com/node-js-javascript/codes-of-conduct-82ab2d88112d

[Albert-IV]

+1 for CoC and +1 for @maxogden's suggestion.

[k1tm]

+1 for CoC - let's also add consideration for geological diversity. The code needs to be set in context of a project with world wide scope and not all participants will be as skilled in a common language. Patience is required. We want a community that fosters inclusion and out reach, and a membership that can make that happen globally.

[isaacs]

@k1tm I think you mean "geographic" rather than "geological" diversity?

@othiym23 Part of the issue with the "who what and how" here is that we don't have an organizational structure ready and willing to take this on. In npm's case, it was easy: as npm, Inc., we could just say "Yeah, we're doing that." I doubt Joyent is willing to take this on (@shammond2000 might be able to effect change there, but at least as of 2013, that was a non-starter for Joyent legal), and there isn't any foundation or other legal entity that would do this.

Lacking that, we could say that the TC is responsible for enforcing the policy (including appointing representatives to do so), and leave it at that. This would work if the scope of the CoC is limited to the project and various project-related channels (IRC, github, etc.) then it would probably be fine. NodeConf has its own CoC, after all. npm's CoC governs an entire social network, so it had to be a bit more robust.

[isaacs]

@othiym23 Yeah, the 48/72 hours turnaround time was chosen by the TC ourselves. We want to be biased towards action, and git makes it easy to revert later anyway if something turns out to be controversial. Once npm has a dozen people wanting to help land patches, it'll probably be less of a scary proposition :)

[radicalsauce]

Huge +1 for CoC - proactively, explicitly creating mindful, welcoming communities makes a huge difference in outcomes.

[isaacs]

@tjfontaine, thank you very much for creating these threads to discuss this subject. That completes the first action item, and it is good to have some public motion from Joyent on this subject.

The second action item is to come to an understanding of what will need to happen to get the rest of the working group to +1 these policies. We'd hoped to have that accomplished by today (2014-11-14), but I don't know if that's realistic.

@piscisaureus, @bnoordhuis, @tootallnate, @trevnorris, @indutny, and I already expressed agreement with the policies in this PR. @orangemocha abstained, but did not object.

@tjfontaine, @totherik, and @danese, can you please bring up what you see as critical problems, or +1 the PR if you are comfortable with it?

@orangemocha, are you comfortable weighing in on this as an individual contributor, now that it is being done as a part of Joyent's official advisory board process? Or is Microsoft still opposed to being involved?

I suggest that we try to get a call scheduled with the governance working group early next week (before the next JNAB meeting) to try to get objections dealt with so we can have a formal recommendation by then.

[isaacs]

(I realize the irony of essentially calling for a forced vote regarding adopting a policy of consensus-seeking, but to do otherwise would be asserting the consequent.)

[mikeal]

@isaacs regarding your comment about enforcement. There's actually another method we could use, we could say that "any party with admin rights" is responsible for enforcement. That would be more than just the TC, it would be all other contributors, as well as the existing moderators of various forums like IRC, mailing list, gitter, etc.

[ashedryden]

@mikeal @isaacs The important thing here is that anyone who responds needs to be trained in the policies and have the ability to discuss them with others before responding. Any response that is made will be on behalf of the entire admin group, so you may want to figure out what the workflow is gonna look like for both response and disclosures will be.

[isaacs]

@mikeal Yeah, but it's not ideal to just say "any admin". It's much more effective to point to a specific org or group of individuals, and especially, to make sure that the recipient of abuse reports can speak for the group and is trained to deal with receiving them -- and oh, there goes @ashedryden's comment popping into the thread saying what I was about to.

[ashedryden]

Oh also -- my personal preference is that people know who is on the committee of people who they're reporting to because you don't want to create a situation where they're reporting to the person/people who are creating an unsafe/unwelcoming environment for them. This gets to be tricky when you have, say a reports@community.org, as they don't know who will ultimately receive the report. I'll have to think about ways to mitigate that.

[mikeal]

@ashedryden that's a great point. For conferences we tend to point people at all of the organizers for abuse reports because we would hope that you could find one of those people in any space we've created where you might be harassed. Would something similar work here if we were to maintain a list of individuals with admin rights in each forum and ask you to report to "any of these people?"

[mikeal]

@isaacs @ashedryden good point on training moderators and admins on this.

[ashedryden]

@mikeal re: who to report to --

I think reporting to any of those people would be good. It may be best to create a form that will email the person they choose and CC all of the admins. The main person would be expected to respond, but all admins would have access to all reports (so they're searchable for future reference) so they can respond if it isn't taken care of in a timely manner. ALL reports and responses could CC the admin group, I'm thinking.

[gramergrater]

So reporting to the person/people who are creating an unsafe/unwelcoming environment should be avoided, but a CC is fine? I think it'd be best to make the cc optional.

[ashedryden]

@gramergrater I just worry that without the CC you risk: 1) people not responding quickly enough 2) other members of the admin team not being kept apprised of all incidents, so they can be recorded and multiple violations from an individual can be tracked

I'm not sure of a way around the issue. As I said, I still need to think a little more about that.

[isaacs]

@ashedryden @mikeal I think that hammering out the specifics of reporting structures might be out of scope for this phase, maybe we can circle back to that stuff once we've established consensus on more of the broad strokes? (Also, Ashe, thank you very much for pitching in with your opinions here.)

[totherik]

Just a few thoughts while I'm digesting everything, but my initial observation is that it would be useful to break the PR into two, separating the Code of Conduct from Governance + Contribution.

I like the CoC, so I'm +1 for that, but I suspect it will evolve over time (see previous comments from others). How is it suggested the CoC itself is governed? Is the TC itself the final authority?

Initial membership invitations to the TC were given to individuals who had been active contributors to Node.

Some clarification might be valuable here. This was done by whom? Under what authority? For how long? In the interest of capturing details as to the bootstrapping of the TC it's helpful, but it seems to be missing information regarding how seats are added, vacated, term-limited (if at all), how individuals in a voting capacity are nominated, etc.

The TC meets weekly on a Google hangout.

What is the agenda and who sets the agenda for this meeting? Is there an open call for the community to vote or have input on topics to be discussed or is that implicitly provided via activity on individual GH issues or PRs?

Each meeting should be published to Youtube.

If this is a goal: s/should/will. Links to meeting minutes and the videos themselves should be readily available from here.

Additional random questions:

• Is TC membership a fixed number? Are seats added opportunistically?
• Should someone step down, are there limits as to how long a seat can be vacant?
• If a seat is vacated, how is it handled should the ratio change such that 1/3 of the seats are held by a single employer?
• Does this (or should it) address realistically address tactical issues such as project management (which @piscisaureus has mentioned is a pain point.)

Thanks for creating this and getting the discussion going.

[isaacs]

@totherik +1 on should/will. Splitting into two PRs could be worthwhile, but meh. Re questions, here's my $0.02:

How is it suggested the CoC itself is governed? Is the TC itself the final authority?

Yes. The TC is the final authority on the project. This would go in the CONTRIBUTING.md file, which is the message to potential contributors about how to interact with the project, and is part of the project. Just like a README.md or any other documentation, if you want it changed, send a PR, and the committers will accept or reject depending on whether they think it makes things better. That's what self-governance looks like :)

Some clarification might be valuable here. This was done by whom? Under what authority? For how long?

Well... these are the folks who had been working on getting Node to self-governance, and appointed ourselves (and TJ and Alexis) to do that governing. None of us objected, so there you have it ;)

In seriousness, the criteria was that this group includes currently engaged core committers, and those with relevant experience and knowledge about running the Node.js project (ie, that's why Bert and me are included). There are no term limits, but disengaged members can be ejected via consensus, and members can resign at any time.

What is the agenda and who sets the agenda for this meeting? Is there an open call for the community to vote or have input on topics to be discussed or is that implicitly provided via activity on individual GH issues or PRs?

I plan to give up my seat once the process is established and we have someone else who can move into a voting role. I believe that @piscisaureus has said the same.

New TC members are added via nomination and consensus of the TC. No more than 33% can share an employer. (Part of the reason why I don't quit yet is because then either Bert or Ben would have to quit as well, and then we're down to a very small committee.)

The upper limit on TC size is debatable, but unlikely to ever be more than a dozen, just given the limits of active engagement.

Remember: the intent is not that the TC is "the set of people with commit rights", but rather "the set of people tasked with making the final decision on controversial changes and project policies". The intent is that many more people will be granted commit access.

What is the agenda and who sets the agenda for this meeting? Is there an open call for the community to vote or have input on topics to be discussed or is that implicitly provided via activity on individual GH issues or PRs?

At the last NFTC call, we decided that it was already getting too difficult to find a time everyone could be on a call synchronously. The idea was proposed that the moderator solicit ideas for an agenda, and then post an issue a few days before the call. Then TC members can either make their position known regarding those issues (and skip the call, abdicating to consensus), or can join the call if something is important to them.

Generally there would not be anything in the agenda that is surprising, and every agenda item will be important to someone. (If the whole TC reaches consensus prior to the meeting, then there's nothing to discuss, and it is removed from the agenda.) This would just be a more formal version of what tends to already happen in this group, so it would seem to make sense.

Is TC membership a fixed number? Are seats added opportunistically?

Addressed above. Yes, seats are added as needed. I think a realistic minimum number of members is 6, or else it's hard to get much done. (It's maybe not really appropriate to think of the TC as having "seats" per se, since the number isn't fixed.)

Should someone step down, are there limits as to how long a seat can be vacant?

Anyone is free to leave at any time for any or no reason.

If a seat is vacated, how is it handled should the ratio change such that 1/3 of the seats are held by a single employer?

If there are 6 seats, and 2 of them are held by StrongLoop employees (to pick just one example), and someone leaves, then one of the StrongLoop employees would also be forced to leave.

If there are 18 seats, and 6 held by IBM employees, and a non-IBM employee leaves, then an IBM employee would have to also leave, resulting in IBM now having 5/16 seats, instead of 6/17. It's up to the individual members who gives up their seat.

Does this (or should it) address realistically address tactical issues such as project management (which @piscisaureus has mentioned is a pain point.)

It addresses the strategic issue such as "how do we address problems such as project management" by providing a forum where the project team can drive the process. The JNAB's job is to advise Joyent about Node; project management is a governance issue, and should be handled by a governing body (which the JNAB explicitly isn't).

[benlesh]

When you add the bit about how to report harassment, can you add a bit about what to do if you see, notice or experience harassment? Be sure to include what to do if you notice harassment of someone else. Knowing that people in marginalized groups are more likely to be harassed, it goes to reason that the majority of people that witness that harassment would be from the non-marginalized group(s), and frankly, might not know how to handle that situation. I think that often people don't feel empowered to do something if they're a bystander because they feel the onus is on the victim to do the reporting.

[isaacs]

@blesh I agree! Good point.

[gramergrater]

Does the 33% rule extend to parent companies?

[rlidwka]

Strong "-1" to CoC, because enforcing it did more harm for this community in the past than whatever CoC was trying to protect against (see my comment above).

"+1" for governance though. TC should consist of the people who write actual code in the core, and nobody else imho.

[gramergrater]

@rlidwka See @mikeal, also is it just me or is there not any comment from you yet?

[yoshuawuyts]

@gramergrater @rlidwka the comment was removed by @isaacs -- https://github.com/joyent/nodejs-advisory-board/pull/11#discussion_r20395043

[rlidwka]

@gramergrater, basically, I'm backing up your comment about intent in https://github.com/joyent/nodejs-advisory-board/pull/11#discussion_r20352425

I'm trying to be as brief as possible here (because it might just get deleted again), but I can explain it all in detail elsewhere (e.g. on reddit).

[ceejbot]

I am delighted to see a code of conduct for node contributors here. The absence of a CoC has caused problems for the project in the past. I was taken aback that even after past difficulties, a formal CoC was not put into place. Its absence is one of the reasons I have hesitated to get involved in node development, though I have both the interest and the relevant background.

This isn't anecdote or speculation; this is someone in the group you're interested in reaching out to saying thank you for this work.

[jfhbrook]

I really dig that the proposed CoC is proactive and addresses specific problem areas. I would like to see it made a little more robust as suggested by Forrest and tweaked with Ashe's suggestions in mind, but in general I'm really excited to see this land.

Having read the governance policy, though, I still don't even know what TC stands for! Maybe I just missed it, but it would've been really nice to have had TC defined/explained somewhere obvious.

[isaacs]

@jesusabdullah TC = Technical Committee. Kinda buried :) https://github.com/joyent/nodejs-advisory-board/pull/11/files#diff-898e7f1ceacb493c024554f5a7c87bdfR3

[mikeal]

@isaacs @jesusabdullah it's buried in the diff maybe but it's actually the first line of the governance section :)

[jfhbrook]

Yeah, I obviously just skipped the first paragraph for some reason. It happens!

[jasisk]

EDIT: Adding a note here because my comment was clearly made when there was a lot of other discussion going on. I wasn't aware of how much discussion was happening at that time (and continues). My comments refer—quite specifically—to making efforts towards embracing, e.g., new and young contributors by being more mindful of our sarcasm/snark. I was thinking of this piece by @derickbailey. I hope that is clear amid everything else.

---

There are many examples of other communities—famously—having fostered a negative environment for new or young contributors by responding to attempts at contributing or engaging with snark, incredulity, or otherwise equally unproductive commentary. I think this could potentially be recognized and discouraged by adding to the section that reads:

In particular, we don't tolerate behavior that excludes people in socially marginalized groups.

... with ...

In particular, we don't tolerate behavior that excludes people in socially marginalized groups, nor will we tolerate attempting to marginalize any particular individual or individuals.

Further, I'd like to see the "trolling" language qualified a bit, perhaps expanded upon to reduce the amount of social-media "shaming." I'm not sure how the specific language should read, I just think it would be valuable and prove more welcoming to state, upfront, that speaking up or getting involved won't result in a, "lol, look at this PR/Issue", etc.

I'm certain we've all been on both the giving and receiving end of this snark or sarcasm, I'd just like to see some language added to discourage it from the beginning; to inform enthusiastic minds—regardless of any particular characteristic including length of time working with node / js / development in general—that they will be supported and won't find themselves on the unfortunate end of a sarcastic comment or tweet.

[totherik]

@isaacs thanks for the thorough response. The comment was partially for my own edification, but also to point out that the level of detail that's now captured in GH comments should be included in the document itself. It may go without saying for those at the center of these conversations, but capturing those ideas (bylaws?) explicitly in the governance document will capture the expectations as they stand today and reduce possible misinterpretation in the future.