[llvm-dev] [PITCH] Improvements to LLVM Decision Making

[David Chisnall via llvm-dev]

On 16/01/2020 06:44, Chris Lattner wrote:
> Yes, I agree.  The model I have seen work in the Swift community is that there is no formal voting or other pre-structured way a decision is made.  Instead, the community provides input to the core team, and the core team (in practice) always goes with the community if there is consensus.  If there isn’t consensus or if the core team believes that an important point has come up but hasn’t gotten enough discussion, then it kicks the discussion back to another round with guidance to focus on specific topics etc.  It is sort of a managed discussion process in practice.

How is the Swift core team selected?

>> There is no formal leadership of the LLVM community.  The LLVM Foundation leadership is self-selected and not necessarily representative, so cannot fill the 'buck stops here' role of someone who has to make the call and justify their decisions when they come up for reelection.
> I agree that this is the hardest part of getting a structure in place, as well as your concerns with the foundation board.  What do you suggest?  Do you have other ideas, recommendations, or a preferred approach?

I've never seen a model that works well in all situations.  I've been in 
a few projects where there's a clear maintainer and as long as most 
decisions are reached by consensus that the maintainer stamps with their 
approval, things work well.  This model breaks down when there are 
decisions that do not have clear consensus, for example moving a project 
to GitHub when a significant fraction of the community have moral 
objections to infrastructure that does not meet the FSF's approval.  In 
this case, there is nothing that the maintainer can do without annoying 
half of the community.

The FreeBSD model works reasonably well.  First, there is an explicit 
notion of a committer as an official project member.  Committers have 
voting rights for the Core Team.  To retain these rights, you must have 
committed something in the 12 months before a Core election.  To become 
a committer, you must be proposed, voted for by the Core Team, and must 
then be mentored by an existing committer, who must approve all of your 
commits for a little while.

We discussed a mentorship system similar to this for LLVM at the WiCT 
workshop and I'd be in favour of something along those lines, 
irrespective of the rest of this process.

There are a few problems with the FreeBSD model:

Being a member of the community is tied to committing code (or docs). 
There are a number of incredibly valuable members of the community whose 
contributions are in other forms.  The WiCT keynote (which is still not 
online as far as I could see!) highlighted the value of these people. 
Decisions made by the Core Team can often affect these people, but they 
have no say in the elections.

FreeBSD also has a large downstream community that is not necessarily 
represented by this system.  In LLVM's case, this community is an even 
larger part of the whole ecosystem.  There are a lot of out-of-tree 
front ends, for example, yet most of the developers of those are not 
represented by our current processes.  It is a mistake to ignore this 
community because it should be one of our primary recruiting pools: 
writing a tool that uses LLVM is the best introduction to starting to 
work on LLVM itself.  The current decision-making process can often 
leave these people feeling ignored.  The monorepo decision was a good 
example of this: it made life easier for active contributors to a set of 
core LLVM projects and harder for a number of categories of downstream 
consumers.  Making these people feel as if they don't have a voice does 
not encourage them into our community.

Electing a core team can work very well if the electorate represents the 
interests of the community.  The LLVM community has a very sharp 
in-group / out-group divide currently and I struggle to see any way of 
defining an electorate for our wider community that would work well.  I 
would love to see more effort made to address this split independently, 
because I think it would give us a more healthy community and a better 
path to a democratic decision making process.

David