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

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

Hi David,

I absolutely agree with the spirit is most of the contents of your response.

Some replies inline.

On Thu, 16 Jan 2020 at 16:21, David Greene <greened at obbligato.org>
wrote:
> "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."
You nailed it. I suggested meritocracy as "one of the" methods of
choosing representatives, not the only one. I also mention other ways
to look for non-obvious candidates, so that we can represent the
multiple dimensions of the community, as I believe is the spirit of
your comment.

> 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.
IIUC, making technical decisions, even final arbitration, is a clear
non-goal of the Foundation.

So far, every big decision we had was done via list threads, BoFs,
socials and in the few cases where it was required, the final
arbitration has been done by Chris.

> 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.
I feel that creating a complex multi-dimensional rotational system
will do more harm than good.

When I said "scalable" I meant we should do what needs done when it
needs done, and not more.

So, we can have a large pool of representatives (by whatever fair
method we find), and whenever a topic needs discussion, those
representatives "subscribe" to the discussion. Topics appear in a
public forum, but not the llvm-dev list, so that it's easy to see
what's being discussed without pulloting day-to-day work.

All those subscribed are expressing that they want/need to be
consulted before a final decision (modulo timing issues, multiple
warnings, strong consensus, etc). People that don't subscribe are
stating whatever decision that is taken is ok for them (and their
sub-communities).

A sub-community can raise interest, in which case their
representative(s) are being strongly encouraged to participate, even
if they themselves are not pesonally interested. Such is the price of
representation (like we ask code owners to be the last line of review
and technical decisions).

Bigger discussions will have more people involved, smaller, less. To
deal with the big ones, an equally organic nature should be taken.
Discussions, consensus and decisions have time frames to be completed,
mostly set by the needs of the problems at hand, so that nothing drags
forever.

As a last resort, some kind of fair voting [1] system can reduce the
pain of representative bias and take some action that is endorsed by a
majority. If we assume a small majority is still better than no
decision, this should work fine, though I'm not claiming it is.
> 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.
I think we need to accept that we won't get it right the first time,
and be ready to change the process, and potentially re-discuss closed
topics, as we go.

Starting from a very simple, flexible and organic system would
probably mean we'll make more mistakes up front, but I hope that it
will result in faster convergence to a system that trully represents
the community.

cheers,
--renato

Suggestion, not endorsement:
[1] https://en.wikipedia.org/wiki/Condorcet_method

Renato Golin <rengolin at gmail.com> writes:
> Starting from a very simple, flexible and organic system would
> probably mean we'll make more mistakes up front, but I hope that it
> will result in faster convergence to a system that trully represents
> the community.
This makes a lot of sense to me.  +1.

                 -David