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

On 15/01/2020 10:04, Doerfert, Johannes via llvm-dev
wrote:
>> "It isn't clear how to propose some changes in the first
place, and it
>> is often unclear who the decision makers are."
> I feel that patches and RFCs are well established*and documented*  [1,2]
> ways to propose changes. In addition, the *-dev lists, IRC, etc. do
> provide ways to clear uncertainties. Adding more documentation on this
> can obviously be helpful. Also, we are already improving the existing
> documentation [0].
This came up at the WICT workshop (which still doesn't have a writeup on 
the LLVM web site) and has previously come up in Cambridge and Paris 
LLVM socials that I've attended and at EuroLLVM:

There is no formal definition of 'the LLVM community' and therefore 
anything that requires consensus of the community is difficult to 
define.  I have spoken to several people who have believed based on 
mailing list discussions that consensus on an issue is one thing, but 
then the decision has been taken to do the other option, often with the 
justification that this was the consensus of the people at a BoF at the 
San Jose dev meeting.

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.

David

> On Jan 15, 2020, at 3:40 AM, David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 15/01/2020 10:04, Doerfert, Johannes via llvm-dev wrote:
>>> "It isn't clear how to propose some changes in the first
place, and it
>>> is often unclear who the decision makers are."
>> I feel that patches and RFCs are well established*and documented* 
[1,2]
>> ways to propose changes. In addition, the *-dev lists, IRC, etc. do
>> provide ways to clear uncertainties. Adding more documentation on this
>> can obviously be helpful. Also, we are already improving the existing
>> documentation [0].
> 
> This came up at the WICT workshop (which still doesn't have a writeup
on the LLVM web site) and has previously come up in Cambridge and Paris LLVM
socials that I've attended and at EuroLLVM:
> 
> There is no formal definition of 'the LLVM community' and therefore
anything that requires consensus of the community is difficult to define.  I
have spoken to several people who have believed based on mailing list
discussions that consensus on an issue is one thing, but then the decision has
been taken to do the other option, often with the justification that this was
the consensus of the people at a BoF at the San Jose dev meeting.
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.
> 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?

-Chris

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