Voting

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... :frowning:

Makes sense? Any ideas?

cheers,
--renato

This proposal of course assumes that the LLVM community is to be run
as a direct democracy. I don't want to distract from your detailed
proposal, but it seems the desired governance model needs to be
defined before delving in to the details of how to implement it. Or
has this discussion taken place somewhere? I'm specifically not
expressing a view one way or the other. I had assumed the current
set-up was some combination of BDFL and decisions being taken by
Foundation board members, but I don't recall this being explicitly
defined - though it would be good if it was. Communities such as
FreeBSD, Debian, and others obviously have rather more involved and
fully defined decision procedures.

To get an indicative view from the LLVM developer community, perhaps
it would be good enough to set up a Google form inviting people to
give their name, email, whether they have the commit bit, and their
'vote'. The resulting spreadsheet can then be easily analysed. I don't
think there's a way to have the email validated in Google forms (i.e.
send an email with a confirmation link), which would be be necessary
to protect against someone theoretically entering false information -
though in practice this may not be an issue.

Best,

Alex

From: "Alex Bradbury via llvm-foundation" <llvm-foundation@lists.llvm.org>
To: "Renato Golin" <renato.golin@linaro.org>
Cc: llvm-foundation@lists.llvm.org
Sent: Wednesday, June 29, 2016 11:02:42 AM
Subject: Re: [llvm-foundation] Voting

> 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.

This proposal of course assumes that the LLVM community is to be run
as a direct democracy. I don't want to distract from your detailed
proposal, but it seems the desired governance model needs to be
defined before delving in to the details of how to implement it. Or
has this discussion taken place somewhere? I'm specifically not
expressing a view one way or the other. I had assumed the current
set-up was some combination of BDFL and decisions being taken by
Foundation board members, but I don't recall this being explicitly
defined - though it would be good if it was.

I'd like to second this. I don't think that we should focus on a direct-democracy model. Such systems work well only for small groups. Having accountable representatives and leaders is better. A smaller group of accountable decision makers can invest more time in understanding the issues and the alternatives in order to make an informed decision. Accountability can come from elections, from the risk of community fracturing, etc.

-Hal

This proposal of course assumes that the LLVM community is to be run
as a direct democracy.

I don't think it does. At least, that wasn't what I was proposing at all.

My point was simply to reach consensus *first*, as usual, then vote
*only* on the most controversial / high impact decisions to cristalize
the consensus into a number. Good examples are version control, code
of conduct, license, etc.

Voting without (or to reach) consensus is a grenade to the foot.

I don't want to distract from your detailed
proposal, but it seems the desired governance model needs to be
defined before delving in to the details of how to implement it. Or
has this discussion taken place somewhere?

This is what we have done as far as I can remember, and is my
interpretation of what we have evolved into.

From previous posts in this list, the foundation doesn't want to be a

driving force, but a supporting force, and I very much support this
view. We have had the model of consensus for a long time and it has
worked very well so far. In that case, the foundation can only make it
better.

I think Chris' words reflect that position well:

"Most things can be done by the community, the foundation should only
step in when there is no ability (e.g. legal issues) or apparent will
(e.g. the website overhaul) to do it."

Communities such as
FreeBSD, Debian, and others obviously have rather more involved and
fully defined decision procedures.

I am confident that this will not work for LLVM.

We grew into a group of mostly agreeable and respectable people, and
politics will only drive us away from each other and tear the
community appart (see Britain).

The day that we *need* politics, the community will be long dead. The
GitHub, code of conduct and license threads are great examples of how
we can persevere against the odds and come up better as a group.

We may not agree with everything, and take a long time to change
things, but we're always moving towards what the collective believes
is better (whatever that means).

Less haste, more speed.

cheers,
--renato

From: "Renato Golin via llvm-foundation" <llvm-foundation@lists.llvm.org>
To: "Alex Bradbury" <asb@asbradbury.org>
Cc: llvm-foundation@lists.llvm.org
Sent: Wednesday, June 29, 2016 1:44:44 PM
Subject: Re: [llvm-foundation] Voting

> This proposal of course assumes that the LLVM community is to be
> run
> as a direct democracy.

I don't think it does. At least, that wasn't what I was proposing at
all.

My point was simply to reach consensus *first*, as usual, then vote
*only* on the most controversial / high impact decisions to
cristalize
the consensus into a number. Good examples are version control, code
of conduct, license, etc.

Voting without (or to reach) consensus is a grenade to the foot.

I understand your point, but I don't think this addresses the problem we have in practice. The problem we have in practice is determining when we have consensus. This is because a small percentage of our community actively participates in any given discussion, and disproportionally loud opponents or proponents can skew the apparent tenor of the conversation.

-Hal

Indeed!! And that's what consensus-then-voting "fixes". It's easy to
blame "few loud opponents", but it's also easy to get distracted by
them.

For example, I did a quick count on people agreeing with GitHub and it
came out as 23 out of 25. That's consensus.

I did the same count on the code of conduct discussion we had, and
that was around 10 vs. 10 on the reporting issue. This is *not*
consensus.

I have proposed voting for GitHub, but I will not propose, nor defend,
voting for the code of conduct. Not at this stage, not until we have a
clear majority. And to have a clear majority, both sides need to reach
a reasonable compromise.

That is the sole reason I support this view: I prefer to reach a
compromise, conceding some of my points, than to force someone to do
what I want, just because I have more friends or am more persuasive.

That's the difference between pure democracy and consensus driven
communities. I don't have any illusion that there isn't politics and
self-interest involved in many decisions around LLVM, but the hard
decisions move slowly and get refined into something most people
agree.

I wanted LLVM to use Git at least 5 years ago. I did propose, and
people did agree, but most considered a contentious issue. So, for the
last 5 years, I've been talking to people, understanding the issues,
finding solutions, as many others have, and here we are, reaching
consensus and getting things done. The right way (tm).

cheers,
--renato

From: "Renato Golin" <renato.golin@linaro.org>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: llvm-foundation@lists.llvm.org, "Alex Bradbury" <asb@asbradbury.org>
Sent: Wednesday, June 29, 2016 2:15:56 PM
Subject: Re: [llvm-foundation] Voting

> I understand your point, but I don't think this addresses the
> problem we have in practice. The problem we have in practice is
> determining when we have consensus. This is because a small
> percentage of our community actively participates in any given
> discussion, and disproportionally loud opponents or proponents can
> skew the apparent tenor of the conversation.

Indeed!! And that's what consensus-then-voting "fixes". It's easy to
blame "few loud opponents", but it's also easy to get distracted by
them.

For example, I did a quick count on people agreeing with GitHub and
it
came out as 23 out of 25. That's consensus.

I did the same count on the code of conduct discussion we had, and
that was around 10 vs. 10 on the reporting issue. This is *not*
consensus.

I disagree, and I think this highlights the issue. I suspect that, if we actually took all of the active participants in the LLVM community and forced them to vote (even if that included an option to abstain), we might very well find that we had consensus on the code-of-conduct issues. You can't determine consensus by counting emails on the mailing list, it is just not accurate. There are practical constraints and social disincentives to sending "voting" emails. Some people will send a "+1" on some issues, but many will not. To determine consensus, we need to vote (either directly or via representatives/proxies).

The other point about voting, which is not to be overlooked, is that Pareto optimal is neither, in general, globally optimal nor strategically wise. This is one reason why leadership is important.

-Hal

I disagree, and I think this highlights the issue. I suspect that, if we actually took all of the active participants in the LLVM community and forced them to vote (even if that included an option to abstain), we might very well find that we had consensus on the code-of-conduct issues. You can't determine consensus by counting emails on the mailing list, it is just not accurate. There are practical constraints and social disincentives to sending "voting" emails. Some people will send a "+1" on some issues, but many will not. To determine consensus, we need to vote (either directly or via representatives/proxies).

You have exposed the problems in my view, and I accept that. But do
you accept that direct voting, lobbying and campaigning will lead to
fracturing problems, dividing the community just like we see in
Debian, *BSD and others?

The code of conduct was approached twice in the period a year, and
that highlights how people are trying to solve it. I believe that the
second time we had less friction, and I also believe that folks were a
bit more open to my concerns, we had less aggressive and more
constructive responses. The concerns around the language of reporting
were made clearer, and I believe Chandler is aware of why we feel
strongly in that way. I'm confident that, if we keep doing this, we'll
reach consensus.

In this case specifically, "voting" would alienate the minority, which
is *precisely* the opposite of what the code was trying to do.

All in all, the code still wasn't necessary, and I think most would
agree that it won't be for the foreseeable future. All problems that
happened that the code could have helped were dealt with directly and
effectively without it.

Having a code is good, rushing a code, through vote, that *knowingly*
alienates part of the community, is not.

The other point about voting, which is not to be overlooked, is that Pareto optimal is neither, in general, globally optimal nor strategically wise. This is one reason why leadership is important.

There are many types of leadership, not all of them beneficial. I
again ask you to consider your points in a global setting and
appreciate the falacies it entails, just as much as my views..

So far, our model has worked well. I don't see any glaring issues to
warrant a sudden change, nor I think we should change just because.

--renato

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

Hi Tanya,

I agree with *everything* you said. :slight_smile:

I'll be glad to help you on that task.

cheers,
--renato

From: "Renato Golin" <renato.golin@linaro.org>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: llvm-foundation@lists.llvm.org, "Alex Bradbury" <asb@asbradbury.org>
Sent: Wednesday, June 29, 2016 3:16:49 PM
Subject: Re: [llvm-foundation] Voting

> I disagree, and I think this highlights the issue. I suspect that,
> if we actually took all of the active participants in the LLVM
> community and forced them to vote (even if that included an option
> to abstain), we might very well find that we had consensus on the
> code-of-conduct issues. You can't determine consensus by counting
> emails on the mailing list, it is just not accurate. There are
> practical constraints and social disincentives to sending "voting"
> emails. Some people will send a "+1" on some issues, but many will
> not. To determine consensus, we need to vote (either directly or
> via representatives/proxies).

You have exposed the problems in my view, and I accept that. But do
you accept that direct voting, lobbying and campaigning will lead to
fracturing problems, dividing the community just like we see in
Debian, *BSD and others?

I agree. As I stated explicitly, I do not think that direct voting works well, in general, outside of small groups. I'm quite happy that LLVM is not a small group.

The code of conduct was approached twice in the period a year, and
that highlights how people are trying to solve it. I believe that the
second time we had less friction, and I also believe that folks were
a
bit more open to my concerns, we had less aggressive and more
constructive responses. The concerns around the language of reporting
were made clearer, and I believe Chandler is aware of why we feel
strongly in that way. I'm confident that, if we keep doing this,
we'll
reach consensus.

In this case specifically, "voting" would alienate the minority,
which
is *precisely* the opposite of what the code was trying to do.

All in all, the code still wasn't necessary, and I think most would
agree that it won't be for the foreseeable future. All problems that
happened that the code could have helped were dealt with directly and
effectively without it.

Having a code is good, rushing a code, through vote, that *knowingly*
alienates part of the community, is not.

> The other point about voting, which is not to be overlooked, is
> that Pareto optimal is neither, in general, globally optimal nor
> strategically wise. This is one reason why leadership is
> important.

There are many types of leadership, not all of them beneficial.

Certainly.

Thanks again,
Hal

I’m not sure if it would help, but the FreeBSD project has spent a few decades evolving its governance structures and may provide some useful example.

In 2000, we move to having an elected Core Team (which, after two terms, I am currently in the process of standing down from). Core Team terms run for two years (though if Core drops below quorum as a result of resignations / death then a new election can be held early). In the elections that we just held[1], we had 325 people eligible to vote and a turnout of around 65%.

The Core Team has the final say on any technical matters, but very rarely has to exercise this power (in my four years, we’ve been asked to make this kind of call roughly once a year on average). Most aspects of the project are run with devolved authority from the Core Team (for example, the documentation team and ports teams are pretty much autonomous, the security team is appointed by Core but then handles all security issues without any further interaction). ‘Flag waving’ is the main responsibility of the Core Team: setting high-level objectives (e.g. ARMv8 should be a tier-1 platform) and then coordinating people / companies to work towards those goals. This is something that’s missing from LLVM (for example, the typeless pointer work is a great idea and will make life a lot easier, but no one in a leadership position is advocating it or - at least visibly - coordinating work towards it). Being elected helps the Core Team significantly in this capacity, because they can claim to represent the majority of committers.

On the side, we also have the FreeBSD Foundation, which is a US non-profit with an annual turnover of around $1m. They explicitly have no direct control over the project (though, in practice, I don’t think that there’s ever been a time since the Foundation was created when the board of the Foundation and the Core Team haven’t had at least a couple of members in common) and are responsible for fund raising, outreach and public engagement (including sponsoring BSD-related conferences and sending FreeBSD developers to other open source conferences, publishing the FreeBSD Journal), and so on. They buy hardware for the project, which is then run by one of the teams that has devolved responsibility form Core. They also fund development work, in two forms. Sometimes there are things that need doing but no one is actively working on them (in LLVM land, providing external consumers with good ways of describing things that follow the C ABI would be top of this list. At other times, they coordinate with companies (who are often direct competitors) to implement features that all of them need, often with additional external funding (for example, the ARMv8 bring-up work was funded by the Foundation, ARM, and Cavium). The FreeBSD Foundation has no direct accountability to the project, but must be seen to be representing the project both to keep its tax-exempt status and to keep donations flowing in.

It’s worth noting that, while certain individuals are on both Core and the Foundation Board, their responsibilities are very different in these two capacities. The Foundation has a lot more flexibility, because it is decoupled from the project and not directly responsible, whereas the Core Team has far greater authority within the project as a result of their elected status. The relationship between the FreeBSD Foundation and the FreeBSD Project is very carefully managed. By spending money on things, the Foundation can direct development to a degree (though no more than any other company that is investing in FreeBSD - a dozen or so companies routinely spend more on FreeBSD development than the Foundation), but its role must be (and must be seen to be) supporting and facilitating, not driving.

The LLVM Foundation is currently in a place somewhere between these. Some of the minutes from the early LLVM Foundation meetings discussed technical issues (inclusion of subprojects) that should be LLVM-the-project decisions, not Foundation issues (though the same people would likely have been making the decisions in both cases). It’s still not clear within the LLVM project (or from outside) where the LLVM Foundation’s authority starts and ends. There is no equivalent of an elected Core Team that serves as an obvious project-side balance for the Foundation.

David

[1] Results have been announced internally, but I don’t think we’ve done a public announcement yet. Given that I didn’t stand this time, I don’t think that I’m giving anything away by saying that I wasn’t elected...

This proposal of course assumes that the LLVM community is to be run
as a direct democracy. I don't want to distract from your detailed
proposal, but it seems the desired governance model needs to be
defined before delving in to the details of how to implement it. Or
has this discussion taken place somewhere? I'm specifically not
expressing a view one way or the other. I had assumed the current
set-up was some combination of BDFL and decisions being taken by
Foundation board members, but I don't recall this being explicitly
defined - though it would be good if it was.

I'd like to second this. I don't think that we should focus on a direct-democracy model. Such systems work well only for small groups. Having accountable representatives and leaders is better. A smaller group of accountable decision makers can invest more time in understanding the issues and the alternatives in order to make an informed decision. Accountability can come from elections, from the risk of community fracturing, etc.

I’m not sure if it would help, but the FreeBSD project has spent a few decades evolving its governance structures and may provide some useful example.

In 2000, we move to having an elected Core Team (which, after two terms, I am currently in the process of standing down from). Core Team terms run for two years (though if Core drops below quorum as a result of resignations / death then a new election can be held early). In the elections that we just held[1], we had 325 people eligible to vote and a turnout of around 65%.

The Core Team has the final say on any technical matters, but very rarely has to exercise this power (in my four years, we’ve been asked to make this kind of call roughly once a year on average). Most aspects of the project are run with devolved authority from the Core Team (for example, the documentation team and ports teams are pretty much autonomous, the security team is appointed by Core but then handles all security issues without any further interaction). ‘Flag waving’ is the main responsibility of the Core Team: setting high-level objectives (e.g. ARMv8 should be a tier-1 platform) and then coordinating people / companies to work towards those goals. This is something that’s missing from LLVM (for example, the typeless pointer work is a great idea and will make life a lot easier, but no one in a leadership position is advocating it or - at least visibly - coordinating work towards it). Being elected helps the Core Team significantly in this capacity, because they can claim to represent the majority of committers.

On the side, we also have the FreeBSD Foundation, which is a US non-profit with an annual turnover of around $1m. They explicitly have no direct control over the project (though, in practice, I don’t think that there’s ever been a time since the Foundation was created when the board of the Foundation and the Core Team haven’t had at least a couple of members in common) and are responsible for fund raising, outreach and public engagement (including sponsoring BSD-related conferences and sending FreeBSD developers to other open source conferences, publishing the FreeBSD Journal), and so on. They buy hardware for the project, which is then run by one of the teams that has devolved responsibility form Core. They also fund development work, in two forms. Sometimes there are things that need doing but no one is actively working on them (in LLVM land, providing external consumers with good ways of describing things that follow the C ABI would be top of this list. At other times, they coordinate with companies (who are often direct competitors) to implement features that all of them need, often with additional external funding (for example, the ARMv8 bring-up work was funded by the Foundation, ARM, and Cavium). The FreeBSD Foundation has no direct accountability to the project, but must be seen to be representing the project both to keep its tax-exempt status and to keep donations flowing in.

It’s worth noting that, while certain individuals are on both Core and the Foundation Board, their responsibilities are very different in these two capacities. The Foundation has a lot more flexibility, because it is decoupled from the project and not directly responsible, whereas the Core Team has far greater authority within the project as a result of their elected status. The relationship between the FreeBSD Foundation and the FreeBSD Project is very carefully managed. By spending money on things, the Foundation can direct development to a degree (though no more than any other company that is investing in FreeBSD - a dozen or so companies routinely spend more on FreeBSD development than the Foundation), but its role must be (and must be seen to be) supporting and facilitating, not driving.

The LLVM Foundation is currently in a place somewhere between these. Some of the minutes from the early LLVM Foundation meetings discussed technical issues (inclusion of subprojects) that should be LLVM-the-project decisions, not Foundation issues (though the same people would likely have been making the decisions in both cases). It’s still not clear within the LLVM project (or from outside) where the LLVM Foundation’s authority starts and ends. There is no equivalent of an elected Core Team that serves as an obvious project-side balance for the Foundation.

Regarding sub projects, it was discussed as to what criteria would be used to accept sub projects from the perspective of supporting the sub-project with resources paid for and administered by the LLVM Foundation. In addition to hosting and infrastructure support, I see the LLVM Foundation supporting official sub-projects in educational services realm as well (workshops, conferences, etc). I do not feel this is a technical issue but an administrative and legal issue. Obviously projects are proposed on the list first (like the parallel-libs project).

As I have said many times before we are supporting the LLVM Project through legal, financial, administrative, and infrastructure. We don’t control the LLVM project in any technical way. We have code owners to handle technical decisions.

-Tanya

For someone interested in how to settle highly contentious topics which are often subjective in nature, might also want to check out the swift-evolution process. Nothing is as contentious, polarizing, and subject to personal opinion as making major source breaking changes to a programming language that has millions of active users :slight_smile:

If you’re interested in the process, it is explained here:
https://github.com/apple/swift-evolution/blob/master/process.md

The archive of proposals that we’ve processed (since December) is here:
https://github.com/apple/swift-evolution

This is a process inspired by several other open source projects as well. I think it would be very reasonable to adapt a similar model to help arbitrate contentious issues like the move to github.

-Chris

A key similarity between what David describes in FreeBSD and what's described in the Swift Evolution process is the existence of a "core team", which has the power to set high-level objectives and make decisions.

Is there significant resistance to establishing such a team? If not, how would we create it? Does the FreeBSD process (=> elections) seem reasonable? Or appointment by the LLVM Foundation?

I was thinking of writing a document somewhere with the final proposal, when we get there. I also like Tanya’s idea of qualitative feedback instead of plain voting.

Our core team is less “core”, since there are many code owners and many non owners with a lot of stake in the project.

Everything looks very much like we’ve been doing anyway. :slight_smile:

Cheers,
Renato

Right, the issue is that "Hosting on github or not” is not a technical issue decided by code owners.

My personal opinion is that the move to github to be something that should be arbitrated by the Foundation itself. There is no point in creating another similar-but-different leadership group in the LLVM community. The Foundation’s purpose is to be that group.

-Chris

To be extremely clear, my choice of the word “arbitrated” was very intentional. This is not a project or process that the Foundation itself should drive - that concept doesn’t even make sense, since we need a *person* to drive this.

My preference is for a motivated member of the community (who ideally is NOT a Foundation board member) to drive and define what it means to move to github, rally support for, and help refine a specific written proposal. Once we have that proposal, then the community can weigh in (I think Tanya’s idea of a web form is a great idea). Then champion can then summarize the feeling of the community, and if it remains overly contentious, the Foundation can help resolve the issue.

-Chris

It seems that the GitHub proposal is finally getting into shape, and
it'll be *a lot* simpler than I was expecting.

Now, it's time to start thinking about how we do the "voting". In
quotes because Tanya's suggestion of survey is a lot better than
simple voting, and folks seem to agree, so we should go with it.

Tanya,

I was thinking "radio" buttons with a few options and a field for
further notes on the reasons. The radio will help us identify raw
numbers, the reasons will help us identify the strength of each
individual choice.

I'm divided if we should have an "other" option, or just go with
"choose the closest option". I prefer the latter...

A draft of the form would be:

Name:
Email:
OSS Project/Company/University (if any):

How do you use LLVM? (choose the closest option)
1. I don't use LLVM, but am interested in its development.
2. I have used LLVM in a pet-project / academic work, but don't use it anymore.
3. I use LLVM on a pet-project / academic work.
4. I use LLVM for a production product / OSS project that we develop /
distribute.
5. LLVM is a major part of one or more products / projects, which
support a bigger product line / OSS distribution.
6. I am a core developer of LLVM, responsible for one or more parts of
the compiler / sub-projects (code owners, top committers,
infrastructure).

Please, expand on your usage, as accurate as you can, with links:
<text field>

How would moving to GitHub impact your usage of LLVM? (choose the
closest option)
1. I already use Git, little to no impact foreseen.
2. I use a mixture of Git and Svn, and some impact will be felt.
3. I use mostly Svn, so we'll have big impact on our productivity.
4. I cannot work with / don't want to move to Git.

If you chose 2~4, please explain your reasons here:
<text field>

The data could be potentially shared, raw, with the community (maybe
the text only upon request, in private communication), so respondents
are expected to not share any private information. Not sharing it
could potentially invalidate any decision taken based on the data and
lead to a fractured community. But companies that have secretive
products can be vague, and due to the nature of the LLVM community, we
should be sensitive to that when analysing the data and drawing
conclusions.

I'm wiling to write up the proposal and do the data analysis (use vs.
impact) and announce the result of the survey. Though, I don't know
what's the best way to do the survey (Google forms? SurveyMonkey?
something else?), and the Foundation's help would be nice. :slight_smile:

cheers,
--renato

It seems that the GitHub proposal is finally getting into shape, and
it'll be *a lot* simpler than I was expecting.

Now, it's time to start thinking about how we do the "voting". In
quotes because Tanya's suggestion of survey is a lot better than
simple voting, and folks seem to agree, so we should go with it.

Tanya,

I was thinking "radio" buttons with a few options and a field for
further notes on the reasons. The radio will help us identify raw
numbers, the reasons will help us identify the strength of each
individual choice.

I'm divided if we should have an "other" option, or just go with
"choose the closest option". I prefer the latter...

A draft of the form would be:

Name:
Email:
OSS Project/Company/University (if any):

Maybe add: how many developers do you have working for you or with you… this might capture large groups of people that don’t want to all write feedback?

How do you use LLVM? (choose the closest option)
1. I don't use LLVM, but am interested in its development.
2. I have used LLVM in a pet-project / academic work, but don't use it anymore.
3. I use LLVM on a pet-project / academic work.
4. I use LLVM for a production product / OSS project that we develop /
distribute.
5. LLVM is a major part of one or more products / projects, which
support a bigger product line / OSS distribution.
6. I am a core developer of LLVM, responsible for one or more parts of
the compiler / sub-projects (code owners, top committers,
infrastructure).

I would remove #6 and separate it into a new question about what the person contributes to LLVM. Either open text box, or radio button list.. I really want to capture the person’s involvement and contributions to LLVM (in technical or non-technical ways..). I think its equally as important as how they are using it. If the majority who fill out the survey are using it but never contribute anything back.. thats an interesting situation..

Please, expand on your usage, as accurate as you can, with links:
<text field>

How would moving to GitHub impact your usage of LLVM? (choose the
closest option)
1. I already use Git, little to no impact foreseen.
2. I use a mixture of Git and Svn, and some impact will be felt.
3. I use mostly Svn, so we'll have big impact on our productivity.
4. I cannot work with / don't want to move to Git.

If you chose 2~4, please explain your reasons here:
<text field>

Sounds good.

I would also have a text box for open concerns or things that may not be considered in the proposal.

The data could be potentially shared, raw, with the community (maybe
the text only upon request, in private communication), so respondents
are expected to not share any private information. Not sharing it
could potentially invalidate any decision taken based on the data and
lead to a fractured community. But companies that have secretive
products can be vague, and due to the nature of the LLVM community, we
should be sensitive to that when analysing the data and drawing
conclusions.

If a company is using LLVM for a secret project.. there isn’t much we can do about it. The will have to figure out how to communicate their concerns without divulging sensitive information.

I think depending upon the results, we can decide how best to present the data.

I'm wiling to write up the proposal and do the data analysis (use vs.
impact) and announce the result of the survey. Though, I don't know
what's the best way to do the survey (Google forms? SurveyMonkey?
something else?), and the Foundation's help would be nice. :slight_smile:

Thank you for volunteering to spearhead this. I would also suggest having a webpage that clearly explains the plan, pros/cons, and then link to survey for people to fill out. Some of this has been on the list, but lets put it somewhere else easily accessible.

I think that anyway is fine (google forms or survey monkey). I used survey monkey for the LLVM Dev Meeting and it worked fine. The Foundation can support costs and help with creation.

-Tanya