[llvm-foundation] Voting

[Tanya Lattner via llvm-foundation]

I proposed on the git hub move thread that a more organized method of gathering feedback be used. A short form that gather important information about who the person is, how they contribute to the LLVM project, how they use it, and how a github move impacts them. We would of course ask if they support the move and why/why not. 

The problem with the mailing list is that the ones with strong opinions can really overrun the people who don’t have time or aren’t as comfortable expressing their views against those who strong opinions. It is also extremely high traffic, lots of responses inlined.. it can easily get muddled. 

By using an organized form to gather feedback, you get an idea of  who is in favor (or not) and exactly why. You also learn a bit about the person who is voicing their opinion and how big of an impact it has on the LLVM project. I also suggest a well communicated timeline for gathering information and decisions. 

I think the LLVM Foundation can create an advisory board with people(board members and not) who are interested in helping determine the end results. This is exactly the sort of area the LLVM Foundation should be helping with as its very administrative and we already pay for and oversee the infrastructure. It also was created to be a neutral role in the community. Obviously the goal is to find the solution that is best for the LLVM project. 

I don’t personally like the idea of a popular vote as its extremely difficult to decide who has “voting” rights and to keep that sort of system up to date. I also don’t think popular is the only metric in the equation. Lets picture a scenario where 2 large companies who contribute to LLVM are on opposite sides.. but the one pro git-hub wins because of a purely popular vote. So that large company forks LLVM. I don’t think thats what would be best for our community.

-Tanya




> On Jun 29, 2016, at 8:22 AM, Renato Golin via llvm-foundation <llvm-foundation at lists.llvm.org> wrote:
> 
> 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
> _______________________________________________
> llvm-foundation mailing list
> llvm-foundation at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-foundation