[llvm-foundation] Voting

[Renato Golin via llvm-foundation]

Hi folks,

I've been thinking, how we're going to do the Git vote. But more
importantly, it would be good to define some guidelines on how we vote
for general issues. So far, we have used consensus as our driving
force, but the number of developers, projects and companies depending
on LLVM is growing a lot, and we're less often reaching consensus now
than a few years ago.

Sometimes, we reach consensus, but a few dissidents still can't see
consensus, and having a vote would go a long way to show consensus has
formed. In that sense, we should only vote *after* consensus was
formed by considering *all* issues on the list.

A few considerations...


  Who votes?

I believe developers without commit access should be allowed an
opinion, but not necessarily a vote. We may have people in the
community whose contributions are important, but ultimately, we must
restrict the numbers somehow. And AFAICR, all important contributors
have commit access anyway.

Downstream users (companies, projects, university research) don't
normally have commit access, but their opinions are also important. I
believe this could be encoded in participating on the discussion
thread and exposing problems with the proposals, not necessarily
voting directly, so I think we don't necessarily need to try to
include them in any category.

Core and current developers will be affected *a lot* more than
occasional and past committers, and code owners have received a
previous vote of confidence from the community, so we may try to gauge
that importance somehow. I don't know how to define "core developer",
though.

Given those considerations, I believe it's important that the vote to
be open and counted.


  The voting process

Since we don't yet have a system where we *must* have a user to work
(like GitHub), it'll be hard to know who voted what when.

We have Phabricator and Bugzilla, but they're not necessarily using
the emails we use for commit, and there are a lot more people than
just committers.

Using a separate Subversion project could work, but counting the votes
would be cumbersome and error prone.

Doodle seem to work more or less fine. I just did a test and we can
choose free text (not just dates), one option per participant, only
invited participants, etc. This would take care of the duplication,
distribution and counting.

But, at least when I tried, a maximum of 20 emails can be used. The
premium version didn't seem to mention that limitation at all. the
other polling systems I found (poll-maker, easypolls) don't even
mention "closed" polls.


  The decision

I believe that any simple majority will bring conflict (just look at
Britain today), so I imagine that we'll need something more
substantial than that, at least 2/3 of the votes.

Also, to avoid quick decisions being made in a rush, through pressure,
we can't have any voting with less than half of the registered voters,
and for less than a week or two. People go on holidays, get sick, have
kids, and we should be considerate to all those issues.

Finally, if I got it right from everyone's suggestions during the
license and conduct discussoins, the idea is that consensus is
paramount and we won'y subvert that in any way, to avoid fracturing a
community that we took such care in building.

So, from my understanding, the Foundation would oversee the voting,
raising all technical concerns and make sure that all points are clear
and precise, but it cannot impose a contrary view, after a decision
has been accepted by the overall majority.


  What to vote for?

This then begs the question: what are the kinds of things we vote for?
And how do we make sure it's fair and for the good of the community?

Voting is a complicated process, and can be quite nasty, especially if
strong opposing views are at stake. Bias and culture can get in the
way of engineering decisions, and we don't want majorities imposing
cultural traits on the minorities (the whole point of the code of
conduct), so we should focus on engineering decisions, not cultural or
personal issues (ex. code of conduct), in which case, pure community
consensus should be reached by the normal ways.

Given that we're talking about technical decisions, I believe good
engineering will always trump personal preferences. Doesn't mean
people can't express their views, but that if those opinions are not
expressed by the vast majority, they can quickly lose weight. Another
reason to steer away from social and personal discussions.

So, moving from SVN to Git is a good example of a voting matter.
People have discussed, proposed solutions, found problems and fixed
them. There is one side that is a lot more likely to "win", so voting
ends up just being a confirmation of the consensus, *not a consensus
forming exercise*.

This last part is really important: we don't want to turn into a
voting-first community, or politics *will* dominate our technical
decisions, and if that happens, I will honestly quit. I believe others
feel the same.


  Next steps

So, I believe we should write up one or two paragraphs with the
intentions of voting in the LLVM community before we start the voting
process itself, to make sure we're not delving into politics. To make
clear it's *just* a confirmation of the already apparent consensus we
have.

After we have the voting, we can begin preparations to move to Git, as
this can take several months... :(

Makes sense? Any ideas?

cheers,
--renato