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

David Greene via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 16 08:21:10 PST 2020


Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes:

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

Given your close attention to representation I know that you have all
the best intentions here, so please take this in the spirit of
productive conversation that is intended.

"Meritocracy" always makes me feel uncomfortable.  Many many people
interpret that to mean those with the most experience/social capital are
best equipped to make decisions.  Not only is that not always true, it
leads to an organization with structural barriers to newcomers, those
with different/less common backgrounds and dissenting views.  I
definitely do not want to go for "meritocracy."

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

Agreed!

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

My first reaction upon reading Chris' proposal was, "Great!  I'm glad
we're finally tackling this."  My second reaction was, "There probably
can't be a single decision-making group."

It's really hard to find a group of people with the passion, domain
knowledge, communication skills and time to make decisions on every
aspect of the project.  Note that by "domain knowledge" I'm including
expertise outside whatever specific technical aspect is under
discussion.  It's meant to be a broad term, not a narrow one that
excludes people.  I think we may want to consider specialty
decision-making groups composed of members who understand lots of
different aspects of particular areas.

For some decisions we might want to form ad-hoc committees (the
git/monorepo decision comes to mind).  It also may be worth having a
handful of standing committees with representatives most interested in
specific areas.  Here's a list of possible standing committees,
generated by me thinking back on various proposals and threads:

- Welcoming community (inclusivity/code of conduct)

- Developer tools and processes

- IR evolution

- Sponsorship/Summer of Code

We might also consider committees that aren't decision-making bodies per
se but carry on various project-wide activities:

- Social (maintain database of meetups, produce resources for social
  activities, etc.)

- Communication (maintain web site, run a Twitter account, etc.)

- Conference organization (would form ad-hoc review committees for
  individual conferences among other tasks)

Not knowing exactly what the LLVM Foundation board does in its
day-to-day work I don't know if one or more of these might fall under
its purview.  In my imagination, the LLVM Foundation board primarily
handles legal aspects, funding and perhaps final arbitration.  I'm not
sure whether it should take on any other formal decision-making roles.

I have some ideas on how to determine membership but they are just
ideas.  We'd want to keep these relatively small (10-20 people in my
mind).  I'm assuming some kind of rotating membership, maybe a couple of
people leave and are replaced each year so that committees maintain
institutional knowledge.  I imagine asking for volunteers and if more
people volunteer than available spots, there could be a membership
backlog where previous volunteers have the right of first refusal when
membership spots open up.  I'm trying to avoid elections and all of the
social problems that come about with them.

Committees would be expected to operate in the open, via public mailing
lists or some other mechanism.  Committees would be expected to solicit
input from the broader community by whatever means they determine best
(a designated mailbox, for example, possibly allowing for anonymous
input depending on the topic).

Learning from other projects will be important.  I am not very familiar
with how governance in other specific projects works.

Maybe formal committees is too heavyweight, I'm not sure, but I've tried
to construct a model to provide a solid framework that improves
inclusiveness and transparency in decision-making.

                      -David


More information about the llvm-dev mailing list