Governance and Membership Requirements

[MylesBorins]

If this team plans to become a chartered working group we will need to determine a governance model as well as membership requirements. I'll use this original post to track the discussion. Currently listing the high level things that need to be determined

Governance Model

• Decision Making Model

Membership Requirements

• Participation Rules

[benjamingr]

I vote for consensus based decision making? Seems to be working well elsewhere so far.

[targos]

What should happen if consensus cannot be reached?

[giltayar]

And, pardon my ignorance, how do we know consensus is reached?

…

On Wed, Feb 7, 2018 at 3:54 PM Michaël Zasso ***@***.***> wrote: What should happen if consensus cannot be reached? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYnRLLWn61y6w9bMuAEPp7ffdynmGhzks5tSarngaJpZM4R58Zv> .

[targos]

@giltayar As long as there are no objections (within a reasonable amount of time), we usually consider there is consensus.

[benjamingr]

@giltayar sorry, I forgot some of us aren't collaborators (yet!) - generally the same way Node does decision making in core.

1. Someone raises a question or issue or makes a PR.
2. Other members debate it for a reasonable amount of time (typically 48h or 72h on weekends)
3. If everyone is in agreement and no one raises an objection - it gets merged.
4. Objections are debated until everyone is in agreement (or in agreement to not block the change).
5. If consensus cannot be reached (often it can with more or more concise discussion) , voting happens. In this case this would either be the team members or the TSC.

In practice, most people agree on most issues consensus seeking has worked in the past. Everyone can voice their concerns and are working towards the same goal. I know modules has been painful for some participants in the past - but I believe the consensus seeking model can work here.

See also https://github.com/nodejs/TSC/blob/master/TSC-Charter.md#section-8-voting for what node does.

[WebReflection]

As long as there are no objections
If everyone is in agreement

AFAIK consensus is different from unanimity, this should be clear to every contributor (or we gonna have hard time doing any change at all).

Objections are debated until everyone is in agreement (or in agreement to not block the change)

I'd explicitly write it in the second way:

Objections are debated until everyone is in agreement to not block the change

If explicit, we can point at it. If it's a sub-clause, it's harder to reason about it.

Again, in favour of consensus but with those points clarified and easy to point at in every discussion whenever if needed. I hope this is reasonable.

[giltayar]

@benjamingr @targos - I must admit, from the little I've seen in these discussions already, sometimes it's not totally clear what we are consensual about, as things keep shifting during the discussion. I keep wanting to say, "OK, but can someone please summarize what the consensus is right now?" :-)

But I admit I'm a junior in these things and will learn as I go along...

[MylesBorins]

So one thing that has been thrown around is the idea of membership requirements. I would like to propose that we move anyone who has not filled out the meeting doodle by the end of next week to an observer status.

I will email the entire group to ensure that people who miss github notifications get a chance.

Does this seem like a fair first expectation for participation? We can discuss this in the meeting.

--> https://doodle.com/poll/vdb8cgz48q3zzt2t

[iarna]

As long as there are no objections (within a reasonable amount of time), we usually consider there is consensus.

People often won't speak up, even in a self selected group like this one, unless directly addressed.

I would be much more comfortable with explicitly polling for "Approve/Disapprove/Tacitly Approve" from every member. (With some mechanism for trimming back membership based on ability to participate.)

Tacit approval refers to saying that you won't block this, even if it's not your first choice (or you don't have an opinion).

Not using a system like this often ends up with decisions being made that some members find unacceptable that they just were unaware of. (TC-39 is still processing some fallout from this problem, re, the semicolons statement.)

[MylesBorins]

@iarna in the past the project had worked with trying to get explicit approval for most decisions. The result of this was that decisions often stalled while we waiting to reach a consensus of at least 50%. TBH my personal experience with explicit polling results in every decision becoming a vote.. and that in turn begins to create partisan lines, even if unintentionally. The project has been making an active effort to make sure conversations are discussed and concerns are addressed before moving forward, and I've generally found that when we can reach consensus without needing explicit polling people are generally happier with the results.

That being said, any explicit change do need sign off. If we are to land documents that in turn reflect a road map or intention for implementation the explicit approval becomes the LGTM or the +1, the tacit approval becomes commenting on thoughts without explicitly giving an LGTM and the Disapprove becomes the -1 or big red x.

Not using a system like this often ends up with decisions being made that some members find unacceptable that they just were unaware of

While this does end becoming the case with consensus seeking, the alternative is that things stll until you reach quorum. If people are actively involved and reviewing issues they have the opportunity to engage in all three methods of response as mentioned above. The primary difference being that the landing of changes doesn't become blocked based on inactivity. In all cases an issue can be blocked / stalled by any individual in the group. For example we have seen PRs on the core side be stalled for a number of weeks while a key stakeholder is on vacation.

FWIW, I don't think our process is perfect, and there is room for improvement and iteration and I think this group could be a great place to do it. It seems that the key difference between our approaches is ensuring everyone has a chance to voice their opinion, perhaps discussing that particular point is a good place to start?

[benjamingr]

Does this seem like a fair first expectation for participation? We can discuss this in the meeting.

Sounds reasonable to me as long as everyone gets notified about it - cc @nodejs/modules so people have a chance to respond and realize it's a different poll from the first one.