Node.js Governance and Contribution Policy

[dshaw]

With #11, we have had a rich discussion around Code of Conduct. We need to move forward on governance, so I have removed the proposals for Code of Conduct and Contribution Policy with the hope of more effectively iterating on each of these giving the the attention and discussion that they merit.

@mikeal mentions in the original post the context for these files:

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.

[dshaw]

@othiym23 @totherik pulling in the discussion. Please let me know if I miss something.

[mikeal]

The governance policy and the contribution policy should be together, the current ones effect and re-enforce each other. You can either add it here or I can do a new PR, up to you.

[dshaw]

@othiym23 mentions:

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.

[dshaw]

Thanks, @mikeal. Added the contribution policy here too.

[dshaw]

@isaacs posted a critical call to action for TC members:

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

[mikeal]

I'm reposting this here so that people don't have to sift through #nodegate in order to find it in the other thread.

---

@totherik I've been trying to adapt what @issacs has been saying in to additional text in the document and have been finding it difficult since, as you may have noticed, a large amount of it has just been informal. Alternatively, I decided to document the points of process that aren't outlined and also improve a bit on them, rather than just describe what has been happening. Let me know what you think about this section being added to governance:

## Agenda

Items are added to the TC agenda which are considered
contentious or are modifications of governance, contribution
policy, or release process. The intention of the agenda is 
not to approve or review all patches, that should happen
continuously on GitHub.

Any community member or contributor can ask that 
something be added to the next meeting's agenda by 
logging a GitHub Issue. Any TC member or the moderator
can add the item to the agenda by a simple +1. The
moderator and the TC cannot veto or remove items.

Prior to each TC meeting the moderator will email the 
Agenda to the TC. TC members can add any items they like
to the agenda at the beginning of each meeting. The 
moderator and the TC cannot veto or remove items.

When an agenda item has appeared to reach a consensus
the moderator will ask "Does anyone object?" as a final call
for dissent from the consensus.

If an agenda item cannot reach a consensus a TC member 
can call for either a closing vote or a vote to table the issue 
to the next meeting. The call for a vote must be seconded by a
majority of the TC or else the discussion will continue. Simple
majority wins.

As I've stated elsewhere, we want votes to be rare and to continue incentivizing people to persuade their peers. I'd like to avoid people calling for votes spuriously rather than working towards consensus so I made it relatively difficult. Basically, a majority has to agree to end the discussion by tabling the issue or calling for a final vote.

I'm interested in people's thoughts. Like I said before, in Node Forward we've never needed a vote and have found easy consensus or the people proposing issues have just dropped and reformulated them, so all of this stuff around voting is new and untested.

@totherik I'm also copying the nomination process to the governance document. Can you let me know any other issues that are still undocumented even if this were added.

[dshaw]

@isaacs mentioned:

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

[dshaw]

@totherik mentioned:

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.

[dshaw]

@isaacs mentioned (and now we are in two PRs):

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

[dshaw]

@gramergrater mentions:

Does the 33% rule extend to parent companies?

[dshaw]

@totherik follows up:

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

[dshaw]

@mikeal mentions:

@totherik I'll point to where I believe some of the current documentation for this is so that you can suggest improvements.

Beginning here we state what the TC governs: https://github.com/joyent/nodejs-advisory-board/pull/11/files#diff-898e7f1ceacb493c024554f5a7c87bdfR26 This should probably be amended to include the nodejs website and some future GitHub org (probably nodejs).

Here we state explicitly that the TC owns its governance model and can iterate on it if necessary https://github.com/joyent/nodejs-advisory-board/pull/11/files#diff-898e7f1ceacb493c024554f5a7c87bdfR32 It may be a good idea in the future to limit the number of seats, for example, and the governance document can be amended in order to do that.

This is how people are added to the TC https://github.com/joyent/nodejs-advisory-board/pull/11/files#diff-c1f8484a7bd248a67b2cd680f19baf8fR20 It is at the TC's discretion what criteria to use when adding new members. I think that is important because the needs of the TC may change over time. Right now it's heavy with people with a history in core because we're getting it up and running but you can easily imagine a future scenario where you would want someone on the TC who is also at ECMA and even though they have little to no track record in core code, bridging the TC and ECMA would be a worthy reason to add them. Additionally, @rvagg has been on the TC calls as a non-voting member but once the build infra is up it would make a lot of sense for him to be a voting member even if he's never contributing to core. These are all smart things the TC should be able to do at its own discretion without guidelines or limitations on membership being written in to concrete today.

In regards to the meeting agenda, I'm actually the one who proposed the new format citing the impossibility of scheduling a meeting with people in Russia, Australia, America and Europe :) But, I think that for the first few meetings it's good to have everyone there and work out whatever schedule needs to be worked out. The first few of these meetings were highly productive because everyone was there. Now the Node Forward work is singing along smoothly and there is less need for everyone to be on a call together. I would hold off on modifying the meeting format/agenda until after a few meetings of the newly formed TC. But, once that change is adopted, it should go in to this document. These policies are all editable, we're never going to get this perfect on the first try, and what works today for Node may be unmanageable a year from now.

In regards to roadmap, the important thing is that the TC owns the releases process, which should be called out explicitly (it isn't in there right now because Node Forward hasn't been doing releases). We've been floating lots of ideas on how to improve the process and get releases back on track but that process, probably more than anything else we're talking about, needs to be iterated on for the lifetime of the project. I think we'll find a great process early on but a year from now when automation is much improved it opens the door to all kinds of new strategies that will need to be explored.

The question that continues to come in both in the Advisory Board and in the community is "how does the broader community participate in the roadmap?" This is a good question and one we're exploring in the roadmap repository in GitHub Issues https://github.com/node-forward/roadmap I believe strongly that the only sustainable way for the broader community to participate in the roadmap is to organize them outside the TC/core in a place and process that they own. The node core project and the TC already work with and even defer to other projects (like npm and v8) so I'm confident that once the community is organized around this that we can create a good relationship between the projects. This is a long way off but luckily there's a long list of obvious and immediate things Node needs to do and release which will give the community plenty of time to think about the long term plans. So the short term answer is "the TC owns the roadmap" and the long term answer is "the TC may choose to adopt a roadmap or participate in a roadmap process with a project which harnesses input from the broader community."

[dshaw]

@mikeal mentions:

@totherik oh, one thing I forgot to mention. The reason I used should rather than must language for the video recordings is that I was afraid technical issues might prevent them from recording properly and I didn't want to commit to them working yet. Having done a few on hangouts I'm ready to try an alternative method for the meetings and would still caution against strong committal language :) But, once we've done a bunch and are confident it all works it should be changed to must.

[dshaw]

@totherik mentions:

Thanks @mikeal, but what I'm hearing is effectively that by not explicitly stating them, any future rights or decisions are reserved, carte blanche. My specific ask was that the governance document explicitly address some of the points I raised. There are answers as to how the proposed TC should function and @isaacs provided them, so I don't see a reason why they shouldn't be included (and based on this proposal they aren't binding or concrete as the TC could change them at any time). You state that the TC owns the governance model, but from what I can tell (based on the provided link) said model consists of 5 bullet points, once of which is "governance" itself. I'm merely asking for more detail as to how the TC will operate and govern itself in addition to Node.js.

Thanks for linking to the contribution policy regarding nominating TC members. I missed that. Perhaps that should be covered in the governance document as "non-voting" participation is already covered there, so the symmetry may be helpful. Also, to be clear I'm not asking that there are criterion for the nominee (the @rvagg example) but that the process as undertaken by the TC is outlined, even at a high level.

Regarding an agenda, I appreciate that it has been fluid. That doesn't preclude a need to have one and if there's a plan for accounting for agenda proposals from the community it would be good to at least outline it at this stage.

I'm not sure I asked about roadmap or releases, so I can't comment on that. I assume that's at the discretion of the TC and any future project management process/policy that will be put in place.

I guess all said, I'm not totally comfortable with publishing a deliberately ambiguous governance model such that the group can operate with impunity. If the guidelines that @isaacs mentioned were agreed upon, they should be documented. At least then there would be a baseline against which proposed changes can be measured once the TC is active in this capacity.

[dshaw]

@mikeal mentions:

Oh, I should also add a paragraph to the bottom:

The moderator is responsible for summarizing the discussion of each agenda item
and send it as a pull request after the meeting.

[dshaw]

@mbonaci commented:

IMHO we should state explicitly that everything TC does must be done publicly. The recording venue should be chosen with that in mind. From the get go.

The only thing I'm not sure about is meetings chat. Perhaps you should decide whether to publish the transcript or read out loud the important stuff, as someone suggested. But whatever you decide should also be stated explicitly in the governance section, along with who is responsible for doing that and in which time frame.

[dshaw]

@mikeal commented:

@mbonaci

The recording venue should be chosen with that in mind.

The meetings are not in person, they are entirely virtual, we're using software that is designed to record the meetings. The problem is: software breaks, especially Google hangouts. I'm looking in to alternatives and once we find something reliable you are right, everything should be public and the contribution policy should be modified to state as much.

Violations of the governance model should have consequences, if the rules aren't followed we should invalidate any decisions the way we would a commit that shouldn't have been merged. With that in mind, I would like to refrain from committing to publicized recordings until we have a reliable solution so that we aren't forced to invalidate an entire meeting's decisions if the recording doesn't work. That does not mean that every effort won't be made to record and publicize every meeting in the meantime.

[dshaw]

@netpoetica commented:

@isaacs @totherik In regards to committee membership:

New TC members are added via nomination and consensus of the TC. No more than 33% can share an employer.

Just a quick point - add some language to consider the case where a member from employer A moves to an employer B who is also represented in the committee already. If employer A has 33% share and B also has 33% share, and this person moves from A to B, they are losing their membership and every other represented party also loses a member (I'm calculating but I could have this logic wrong).

It seems strange to me to tie representation to employer and not individual, but I also believe that no single company should have a majority representation. Just a thought.

[dshaw]

@Fishrock123 commented:

@netpoetica in that case, the rule still stands that no employer can hold more than 33% and the situation you described would play out to, as you said: "they are losing their membership and every other represented party also loses a member.".

[dshaw]

Alright. Thank you all for putting up with the spam to allow us to focus on these issues independently. To you now, Core Team Working Group.

[totherik]

Thanks, @dshaw, for migrating so we can have focused discussion.

@mikeal thanks for putting together the agenda proposal. Yeah, even though votes may be infrequent, establishing a framework for discussion (whenever it happens) is important, and I certainly agree that it'll evolve over time. This all will, so it'll be good to have a baseline from which to iterate. Just a few thoughts (none of which really affect the proposed verbiage):

• One tactical point: it may be nice for TC members to appropriately label issues filed as agenda items, too. This may be useful for transitioning existing issues into agenda items as well.
• Are meeting minutes kept aside from the AV recording? Just reading the "does anyone object" paragraph and I think minutes should be taken to capture the discussion around contentious points, especially if there's little confidence in the recording software. Just read the addendum. For the moderator's sanity it may be helpful to 1) have multiple people help maintain minutes simultaneously or 2) rotate people who do it.

Moving on to some of the other items @isaacs explained that I think should go into this proposal:

Committee Bootstrapping

Just a short clarification around the original inception of the TC and who dispensed seats, etc. In short, we should include some version of the additional detail furnished by @isaacs: "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)."

Membership

"There are no term limits, but disengaged members can be ejected via consensus, and members can resign at any time."

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

Seems like these points are worth calling out explicitly.

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

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

Just thinking it's important to call out that there is no intended fixed size. It could accompany the existing nomination verbiage.

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.

I like this clarification.

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

This has been touched on in other comments as well (@netpoetica, @Fishrock123, et al). The details (e.g. maths) are not as important, but I think it would be good to call out that if an action of the TC (resignation, removal, etc) causes the "33%" bylaw to be broken, an employee of the offending company will be removed from the TC without consensus. Said member can self-select, but TC membership will necessarily change without the need for a vote.

That's all I can think of for now and hopefully it's clear. Thanks for the hard work on this!

[isaacs]

+1 from me on incorporating @totherik's suggested clarifications. They don't change the substance of the process, but do make it more clear, both of which I like :)

[mikeal]

+1 from me as well. Also, this builds on the agenda section which needs to get added to the PR.

[orangemocha]

@isaacs , @dshaw

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

For the time being, I still wish to limit my involvement to being an observer. Furthermore, I am not a member of the advisory board (but Microsoft Open Technologies has a representative there).