[llvm-dev] [PITCH] Improvements to LLVM Decision Making
David Chisnall via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 17 09:36:59 PST 2020
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.
More information about the llvm-dev