doc: adjust voting rules

[mhdawson]

We sometimes have trouble getting enough members to vote, this
update to the voting proceedure ensures we are not blocked
on members who don't vote on a particular issue.

[mhdawson]

@nodejs/TSC as discussed at the collaborator summit.

[mhdawson]

It is noted that this will require board approval. If we get enough TSC support then I'll put it on Myle's list to take to the board.

[Trott]

Unpopular opinion: I am -1 on this. This change further enables disengaged governance membership, which just cascades into other problems. It addresses the symptom (an inability to get sufficient votes) without addressing the root cause (we permit governance members to be disengaged).

If our governance members can't find the time to pop into an issue and say "I abstain." of "I defer to others on this" or whatever, they should remove themselves from governance. If we are derelict in our duty to cultivate engaged governance members, then it ought to cause problems.

[fhinkel]

@Trott 's points are valid. But I think we can address the problem with disengaged governance members separately.

There's the case, where somebody is very busy for a short period of time but otherwise engaged. It would be a shame if a PR gets stalled, because I took a 3 week vacation or something similar.

I think the proposal makes a lot of sense.

[fhinkel]

LGTM. Thanks!

[MylesBorins]

LGTM

[MylesBorins]

I agree that we need to come up with language for disengaged TSC members... but considering that missing votes can happen just as easily due to noise:signal I think this makes sense as a stop-gap

[ofrobots]

Comments from @Trott around engagement are very valid, but I think they can be tackled independently.

[mhdawson]

After quick discussion with Rich I'm proposing this for a vote. Please cast your vote.

[mhdawson]

+1 from me

[jasnell]

+1

[MylesBorins]

+1

…

On Oct 13, 2017 7:21 PM, "James M Snell" ***@***.***> wrote: ***@***.**** approved this pull request. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#378 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV91PF5MNVakJLcVhuBhW8iZ6tZvYks5sr_BdgaJpZM4P0ooo> .

[addaleax]

Somewhat on the fence as well due to what @Trott mentioned, but yes, I think this is okay

[addaleax]

Also since the team hasn’t been @mention-ed yet: @nodejs/tsc

[fhinkel]

+1

[mcollina]

LGTM

[Trott]

So, it's pretty clear this is going to come to a vote and I'm going to be outvoted on this one, which is exactly what I expected (and is why the first words I typed were: "Unpopular opinion").

That said, here's the case against this. If nothing else, I really need to know that this message has been heard:

• We spend an inordinate amount of time addressing the wrong things because it's easier than addressing the root causes. I think this is a pretty good example of that.

• I wish we'd spend less time word-smithing and rule-tweaking and more time recruiting and nurturing effective leadership. These are not mutually exclusive, but the latter requires eliminating absent and/or ineffective leadership, which we're pretty terrible at and this rule makes harder to do.

• I think it's glaringly obvious that we have a huge elephant-in-the-room problem we're not addressing when our reaction to "7 people in leadership roles can't be bothered to drop into an issue after multiple pings and type the words 'I abstain'" is "let's rewrite the rules so they don't have to do that" and not "how do we get them more engaged".

• The "we can do both!" is unconvincing because the primary impact of this rule change--and perhaps the only significant impact--will be to reduce the urgency of improving leadership engagement. This is really bad because improving leadership engagement should be at or near the top of the list of priorities of this body right now. So anything that enables disengaged leadership works against the best interests of the project.

[Trott]

Addendum: "We can do both" works for me if we deal with the bigger issue first and do the rule change second. (That said, who am I kidding, this rule change is totally coming to pass, and when it does, I will accept it and move on.)

[Trott]

It would be a shame if a PR gets stalled, because I took a 3 week vacation or something similar

This is a valid concern. I think it argues against this rule change.

• Vacations and whatnot would impact a very small number of votes unless there are a good number (say 5 or maybe even 8) of people on vacation all at once. Which seems like a good reason for waiting an extra week or three to get to a decision, TBH.

• If one person being on vacation is stalling a vote that would be unstalled by an auto-abstain rule, that means the vote must be very close and it is actually worth not coming to a resolution without that person's input.

• We don't usually have votes that close. What we usually have is votes where there are 6 or 8 people who haven't indicated that their vote or abstention. IMO, that's a different problem that requires a different solution.

[Trott]

missing votes can happen just as easily due to noise:signal

True. In those cases, I'd prefer a rule that we ping out-of-band, like via email and IRC. If someone isn't even aware of the vote (because of noise:signal), auto-abstaining seems like a disservice.

[Trott]

If I'm not mistaken, the vote right now appears to be 11-to-1 so it's official, this rule change passes. (TSC is 20 members right now, so 11 votes is a majority.) I'm assuming a green check mark means a yes vote, whether or not it was provided before or after the call for a vote. That seems reasonable to me, but if anyone else disagrees, we can leave this open and I can comment more about how I'm opposed to it. No one wants that, so let's call it done. :-D

Yes votes were: @mhdawson @mcollina @ofrobots @fhinkel @jasnell @MylesBorins @evanlucas @thefourtheye @addaleax @cjihrig @joyeecheung

[Trott]

Because this has come to a resolution, I'm removing the tsc-agenda label. Feel free to re-add it if there's a good reason to put this on the agenda this week.

[MylesBorins]

I think we should still discuss in the meeting. This seems like a vote that should require more engagement... Ironically

[mcollina]

I understand your feelings @Trott, and I share them 100%. However this issue is the exact symptom of the status of the TSC: 11 people reviewed it in 6 days. In this status quo, we need to be able to operate even if with a reduced speed.

[rvagg]

+1 and I share your concern @Trott but on balance I think greasing the wheels here is easier to address than the larger problem you're pointing to

[Fishrock123]

I agree with @Trott here and would prefer to abstain.

[MylesBorins]

On second thought I'm -1

[MylesBorins]

I'll expand on my -1

I think it solves for the symptom and not general problem regarding engagement + signal:noise. While it may help with the problem today, I am concerned about making it a long standing rule enabling the disengaged behavior we are currently having a problem with

[Trott]

Including mhdawson as a vote in favor, this still passes: 10 votes for, 2 against (me and MylesBorins), and one abstention (Firshrock123). Unless someone else changes their vote, this can go to the board for approval. (It's a charter change, so the board has to approve it.) It has exactly the number of votes it needs to pass.

[Trott]

I'm going to close this because it seems to have stalled. If someone wants to pick it up, I think the next step is board approval since it's a charter change. I'm personally opposed to this change so
¯\(ツ)/¯. But it has enough votes to go through if the board approves it. If someone is going to champion it for that, please comment or re-open.

[mhdawson]

I opened this because at NI it sounded like people were frustrated that we could not get closure in some cases or it took a long time. I'm happy to leave this as is unless somebody else has strong feelings....