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

[Renato Golin via llvm-dev]

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