Consensus and Voting Model

[tjfontaine]

Below is from an internal thread from the advisory board, included here to start the discussion.

Consensus and Voting

@shammond2000

• I think this project has outgrown the BD model so consensus makes sense.
• I like a consensus model but am not crazy about voting and majority. Can you help me understand the thinking behind this? When there is voting, some members may frequently be in the minority, become disenfranchised, and take to social media to vent... Lively debate and consensus tend to lead the group to do the right thing for the project.

@isaacs

In a consensus-seeking model, a decision by majority vote is a last resort, done in cases where the cost of continuing to seek consensus is higher than the benefit of consensus. This would mean either (a) intractable conflicting opinions where consensus is impossible and compromise is harmful, or (b) subjective choices that are not essential and thus are not worth continued debate (ie, bikesheds).

In the case of (b), identifying that the choice is a bikeshed, and taking a vote early, can be the best way to make progress. We can argue all day about the optimum number of spaces to indent, but I think we'd all prefer to have sub-optimum indentation if it means we can stop talking about it.

In the case of (a), indeed, this can be problematic, and should not be treated lightly.

In order to avoid further conflict (ie, taking it to social media), the decision to resort to a vote should itself be reached via consensus. Unless all parties can honestly agree that putting aside their preference is better than continuing to debate, it's unhealthy to push for a vote.

If there is persistent intractable divergence of priorities or technical choices, then it could be that a fork (either a truly divergent fork or just experimental branch) is the best course of action. Exploring the option usually makes it clear whether or not it's a good idea.

Unless voting is an option, an overly rigid policy of "debate until consensus" tends to award the most power to whoever is willing to talk the longest. Voting is an important option in a productive consensus-seeking model. I disagree that it leads to disenfranchised venting; in fact, it can help prevent exactly that.

@danese

At Apache, a vote is measure of consensus rather than a majority poll. Votes are time-bounded, and the convention of "+1, 0, -1 (with supporting argument)" creates a simple shorthand for judging how close the question is to an acceptable conclusion. We believe minority interests are better served by the -1 (with reason) veto vote, since it requires the majority to address their position.

Deadlocks in the Apache consensus process are most often solved by appeal to a designated lead or group of leads, although consistent failure to resolve disputes can be escalated to the Board (who would assign a mentor to try to resolve the issue).

There are a very few types of decisions that cause a majority vote. They are: -Electing new Members, -Electing the Board (which happens every year, although the actual composition of the Board normally changes only slightly), -Banning a Participant -Closing a Project

Of course not every action necessitates a vote. Apache projects run day-to-day on a lazy consensus basis; consensus is assumed with the understanding that any action can be revoked if protested.

[mikeal]

In the current BDFL model the contributors fell in to a pattern I'd call "fight for my patch." This meant that people pushed hard to get their code in through the one person with the authority to land it as well as any naysayers along the way. I can think of instances where this dynamic played out in ugly ways under every project lead and so I am convinced that it is the fault of model and not any of the individuals who have had the role.

The consensus seeking model that Node Forward adopted has created an all together different environment. In consensus seeking the goal is to win over the other participants and everyone is invested in making progress rather than tying people up in the process. At the same time, no individual can be a road block like you get with pure or full consensus.

In the time that we have been using this model several contentious issues have been raised. What usually happens is that people's concerns are alleviated quickly or the person proposing the change simply withdraws it in order to reformulate it in to something that is more easily accepted by their peers. It has been almost two months now and we have never resorted to voting.

At the end of a discussion I simply ask "does anyone disagree?" and we move on. I'm actually amazing at how well it has worked so far. I would caution against the modifications that are being proposed.

Going to pure consensus for certain kinds of decisions is ill advised. It removes the incentives for someone voting against a motion to try and convince their peers. I've seen this play out in pure consensus political groups I've been involved in and it's real ugly.

Going to formalized or forced voting is also an unnecessary and rigorous process. The more you call formalized votes the more people don't consider them strange, which is what you want. You want the participants always moving in the direction of easy consensus and not calling for a vote rather than continuing to work towards it. Voting should be a last resort, and should feel like last resort to the participants rather than something you do routinely. The much simpler "Does anyone disagree?" works much better, it puts the onus of thought and process on those that are against a motion rather than on those that want to get things done.

For reference, the governance structure is documented here: https://github.com/joyent/nodejs-advisory-board/pull/11/files#diff-898e7f1ceacb493c024554f5a7c87bdfR35

[isaacs]

Just to add to what @mikeal has said, frequently someone has disagreed when we've asked "Does anyone disagree?" It's not taboo to disagree, and it is usually a source of very productive discussion.

In both BD and pure-consensus models, disagreement becomes a source of angst. In a BD model, there's a chance that your disagreement will be shut down without being heard (the "benevolence" of the dictator would hopefully make this rare, but people are human). In a pure consensus model, disagreements are often perceived as a way to stall the process, and there's some social pressure to not be seen in that way.

A potential fallback to well-established voting rules reduces the pressure to achieve consensus, which ironically makes consensus easier to achieve. A vote seems weird, and no one wants it to get there, but we're also not afraid to make our minority opinion known, and those in the majority have no need to try to shout us down.

[mikeal]

To follow up on what @isaacs is saying, the reason consensus seeking seems to work is that in all ways possible it incentives individuals to convince their peers. In BDFL and in full consensus people who disagree are not properly incentivized to convince their peers upon disagreement and it would also appear that routine voting could produce similar incentives in a consensus seeking model.

[piscisaureus]

A consensus model is nice, but I will argue that the major problem with node isn't disagreement, it's lack of decisiveness. Consequential decisions are almost completely avoided; only minor changes are made, everything else just piles up in the issue tracker or some other to-do list.

I'll give an example: https://github.com/joyent/node/issues/8704 A patch that that @bnoordhuis landed onto the v0.12 branch turns out to be controversial. There has been a discussion between people for and people against the patch. Now it's time to make a decision, but nobody can do that with authority.

Another: will v8 upgrade to 3.29 or 3.30 before v0.12 drops? There's been discussion but nobody draws a conclusion.

There needs to be a process for making real decisions. It could be a weekly meeting, then someone could put the issue on the agenda and be assured that at the end of the meeting it's clear what "node" is going to do.

I agree that general consensus is much preferable to forcing things through with minimal majority. So consensus should be our goal - let's not be stifled by fear of disagreement. A voting procedure makes a great stick.

[mikeal]

@piscisaureus I added an "Agenda" section that discusses how agenda gets added to the meetings and how votes are forced, does that properly address these concerns?

https://github.com/joyent/nodejs-advisory-board/pull/13#issuecomment-63194925

Also, didn't the v8 upgrade land in node-forward with a quick and easy consensus?

[piscisaureus]

@mikeal

I added an "Agenda" section that discusses how agenda gets added to the meetings and how votes are forced, does that properly address these concerns?

It's a good start, but we can talk about the details. I think I would just have a github label which says "discuss-at-next-tc-meeting". It would also be good if the person that puts the issue on the agenda provides a summary (in a github comment) and formulate what motion exactly is to be discussed.

Also, didn't the v8 upgrade land in node-forward with a quick and easy consensus?

Yes, because node-forward actually discussed this. But for joyent/node that doesn't happen.