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

[Renato Golin via llvm-dev]

On Wed, 15 Jan 2020 at 06:58, Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Numerous people have been bringing up challenges with consensus driven decision making in the LLVM community.  After considering this and seeing the frustrations it is causing many people, I think we should make a formal process change to help improve decision making going forward.

Hi Chris,

Having proposed this many years ago, I think it's a good move forward. :)

I also mostly agree with your points, here are just some additional
material to think about.

My main concerns about the current model:
 * You get hit by a bus (hopefully not that drastic, but other life
changing moments can occur).
 * You get a lot of pressure to take decisions that are guaranteed to
divide the community (bad for mental health)
 * You defer to "the community" to avoid mental health breakdown, then
chaos ensue (we have good examples)
 * At the end of chaos, we get to a certain solution, again, with the
community divided

This is the main problem with the "benevolent dictator" model, and I
think it's worse for you than it is for most of us.

I have had a few bad experiences (a no good ones) in building a
decision making body that represents a diverse community, and it boils
down to representativity.

If an unelected body appoints people, no matter how trusted and
truthful they are, the community will already be divided with the
inherent bias (intentional or not).

If we want to go for meritocracy, which I think most people would
agree, then it would have to be people that already represent the
community, internally or externally.

Active code owners is an easy solution, but also fraught with problems
(like what constitutes an active code owner?). It also leaves external
active users from the equation (all the languages and side projects).

Perhaps we could refine the definition of a code owner as one that
actively participates in or around an area and refine the list to
include external users as well, for example Swift or Julia owners.

Code owners are already somewhat elected by either creating the code
base (back-end, passes) or stepping up and being accepted by the
community. Existing code owners can also step down and propose others,
which are again accepted or not by the community. This is a reasonably
democractic process, even if not encoded, and I think it's the closes
to representation we have.

But we also need representation of the users and wider groups that do
not relate to code, and I tihnk that's where the foundation comes in.
We should also look for other opportunities (ethnical groupos?
minorities?) to provide their own point of view.

Hoewever, I'd strongly advise against a simple voting system.

After all, technical decisions should not be taken by the opinion of
the majority, but by strong and corroborated facts. True, those also
tend to fall into categories (see GihtHub PR vs Phab, both sides have
strong points). But voting should only be a last resort, when there is
no clear majority on any side.

Voting systems also create biase in themselves, by over/under
representing certain groups in the number of members allowed to vote.
This will create yet another meta-argument and it'll drag us forever.

If we stick to facts first, and ask the representatives to bring any
concerns their sub-community may have, and we collate all of those,
and there is a clear majority, then the process was fair. Not everyone
was happy, but that was never possible to begin with, so it's ok.

We should also differentiate between code, process and community
changes. Examples are new passes, GitHub and policy discussions. They
need very different time frames, from weeks, to months, to years, not
necessarily respectively.

We also need to be scalable. If we have a decision that only affects a
small part of the code, we can handle in the sub-community (like we
currently do RFCs), but if some points may affect a wider range (like
stepvector in SVE), then we need to widen the scope, involve more
people, and we need those people to be pro active and responsive.

Finally, I think we need to be flexible.

If new information comes to light, or if someone was on extended
holidays and didn't catch up, etc. We need to make sure we don't just
alienate a sub-community because of a rigid process.

After all, the end goal is to make better decisions without burdening
the same few individuals every time or fragmenting the community.

cheers,
--renato