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

Wed Jan 15 03:11:14 PST 2020

+1 from us on this.

The only caveat I'll add is:

   - Getting the right mix of representatives is key.
   - You need a chair that'll do the book-keeping but be impartial to the
   decisions.
   - Having a nuclear option of 'the representatives cannot agree' is
   important too.

Drawing from some life lessons when I spent 5 years designing Vulkan as
part of Khronos, the general philosophy was that we'd discuss until we came
to a consensus on an issue. This meant we definitely spent more time than
was required to solve the technical issues, but I think in each instance
the time sunk was of benefit to the individual design decisions we took.
But you always need the nuclear option *in that sometimes pushing through
any decision* *is better than the paralysis of none at all*. In Khronos it
was done with a one company / one vote -> majority passes. This was
clean-ish there, but failed to take into account that huge companies like
Google might have two very different teams working on the technology
internally that might have differing views, which couldn't be represented
cleanly. You also don't want to overbalance the decision making process by
having all representatives from one/a-few companies (this would be way
worse than the BDFL we have currently!).

Cheers,
-Neil.

On Wed, Jan 15, 2020 at 10:42 AM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Neil Henning
Senior Software Engineer Compiler
unity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200115/030f0c79/attachment.html>