[llvm-dev] [cfe-dev] RFC: Code Review Process
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 7 15:15:54 PDT 2021
On Thu, Oct 7, 2021 at 3:02 PM Renato Golin <rengolin at gmail.com> wrote:
> On Thu, 7 Oct 2021 at 22:31, David Blaikie <dblaikie at gmail.com> wrote:
>
>> This is how we've always done it so far and it has been working well. At
>>> least most people I know think that this is better than most other
>>> alternatives, including ad-hoc decision making plans.
>>>
>>
>> I'm not sure I'd say it's been working well - it took a lot of time, a
>> lot of volunteers and dragging some folks along in the end anyway. I think
>> there's a lot of merit in having a more structured (honestly: faster)
>> decision making process. We often end up in choice/analysis paralysis -
>> where it's easier to object than to address objections, which is tiring for
>> those trying to make change & slows down things quite a bit.
>>
>
> Right, "working well" can mean multiple things... :)
>
> Most people I spoke about this over the years think that it's still better
> than other models, like "benevolent" dictator, "meritocratic" authority,
> diverse types of voting systems, elected "officials", etc.
>
> There are plenty of big projects that follow those models and ours seems
> to be the most inclusive and open to diversity, but not the most efficient.
> I think that side of our community still attracts a lot of people from all
> over the world and is an identifying trait.
>
I don't think diversity necessarily relates to this aspect of managerial
structure. Unless we're talking about the less benevolent dictatorships
where the authority figures both provide structure, but also set some
fairly negative tones for how people should relate. Those things aren't
necessarily connected though, and I don't see signs that's the kind of
leadership we have or are moving towards in the LLVM community.
> But this is mostly on the technical but not code decisions. Code decisions
> I think we can be pretty efficient.
>
I think the code decisions also have some problems in LLVM, for what it's
worth - "yes" is moderately easy (usually if someone feels empowered enough
to say "yes" it's because they are, the rest of the community is
comfortable with it, and you go forward with the work that's been
approved), but "no" is hard to come by - absence of feedback/clear sense of
ownership and authority can make it quite difficult to figure out how to
approach an issue. Who's empowered to approve or disapprove of a patch
that's on the edges of acceptability is quite often unclear (with various
power vacuums opening up as key contributors/project founders have moved on
to other focus areas), and what steps would be necessary/sufficient to make
forward progress may be less clear still. Steps like the Contentious
Decisions Process I think is a step to help mitigate some of that, though
there's still a lot of gaps.
- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/7da6f7a5/attachment.html>
More information about the llvm-dev
mailing list