Skip to content

Conversation

@Octachron
Copy link
Member

This PR is based on top of #55, it proposes to amend the description of the vote procedure to make it clearer that the vote procedure is more intended as a map of opinions — in particular for bikeshedding matters — rather than a final judgement on a technical disagreement; and that consensus should be the aim of the committee whenever possible.

@goldfirere
Copy link
Contributor

The new bits look good to me.

In some sense, we use voting to create consensus. That is, we want to decide by consensus. But when that is elusive (especially for personal-taste matters), mapping out individuals' preferences and presenting the results back to the group drives consensus-building, because we all generally are likely to agree that many votes for one choice are a good reason to prefer that choice.

There is an interesting failure mode here, where individuals disagree even on whether something is a matter of personal taste. For example, suppose we're considering two different concrete syntax choices. Some folks think it's just a matter of personal taste... and suppose choice A has broad support. But now suppose one member of the committee realizes that choice A is very difficult/impossible to parse. Even if a vote is reported supporting choice A, choice B might become the consensus choice because once we have technical content, the "vote drives consensus" argument stops working -- exactly as it should.

So maybe this isn't a failure mode, but more of a success mode. In any case, it all is in agreement with the text written here. (That is, I'm not proposing any amendment, just musing on the nature of voting within this committee.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants