Hi Alex,<div><br></div><div>Thank you for trying to solve a very real problem.</div><div><br></div><div>I'm not sure this method will work -- but we'll never know without trying. Either way, your willingness to act and do something is very much appreciated by me personally.</div><div><br></div><div>Yours,</div><div>Andrey</div><div>---</div><div>Compiler Architect</div><div>NXP<br><br>On Sunday, August 27, 2017, Alex Bradbury via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all. I'm assuming most people reading this email are familiar with LLVM's<br>
code review process <<a href="http://llvm.org/docs/DeveloperPolicy.html#code-reviews" target="_blank">http://llvm.org/docs/<wbr>DeveloperPolicy.html#code-<wbr>reviews</a>><br>
as well as LLVM Weekly, the development newsletter I've written and sent out<br>
every Monday since Jan 2014. Since that time, it's provided something of a<br>
"signal boost" for important mailing list discussions and commits. I feel it<br>
could play a similar role in helping patches that are stuck waiting for code<br>
reviews, or drawing attention to submissions from first time contributors.<br>
There may be alternative or complementary approaches to tackling this<br>
perceived problem we should discuss - I'm coming from a position of trying to<br>
apply the tools I have at my disposal. Also see my previous thoughts on this<br>
issue <<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-November/106696.html" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2016-<wbr>November/106696.html</a>>.<br>
<br>
I don't think it's controversial to suggest that while the code review process<br>
works fantastically well a lot of the time, some patches fall through the<br>
cracks and long delays in review feedback can put people off contributing to<br>
LLVM. As was pointed out in response to the last RFC, very long review times<br>
are problems for long-time contributors as well as newcomers.<br>
<br>
My proposal is simple: add a new 'Review corner' section to LLVM Weekly to<br>
help highlight patches that need more reviewer input. There are two main<br>
categories I'd like to focus on:<br>
1) patches from first-time contributors<br>
2) patches where review activity has died off (i.e. they're 'stuck').<br>
<br>
Obviously this is something that I can just go ahead and do, but I'd<br>
appreciate feedback on whether this would be useful, as well as the specifics<br>
of my proposed approach. I'd argue such a listing does provide value above and<br>
beyond the firehose of {llvm,cfe}-commits, as the two mentioned categories are<br>
not easily discoverable.<br>
<br>
How to select the patches to include? I'm going to rule out manual curation -<br>
LLVM Weekly is already a large time commitment and I'm not convinced trawling<br>
llvm-commits is the way to about this even if time weren't a problem. Instead<br>
I suggest that authors of patches that have got stuck in the review process<br>
should submit their work for inclusion via a simple web form. If reviews have<br>
stalled for a given period of time (1/2 weeks?), just submit a link to the<br>
patch, and up to two sentences describing what the patch does and why people<br>
might want to take a look at it. This might also be used to highlight patches<br>
that aren't short of reviews but could benefit from a wider audience<br>
(obviously if changes are large enough, an RFC should be submitted to<br>
llvm-dev/cfe-dev as usual). The Phabricator API could be used to identify<br>
patches from first time contributors for automatic inclusion, and ideally to<br>
track the stats related to previously included patches (perhaps generate and<br>
include credits for those who stepped up and helped review the previous week's<br>
list?).<br>
<br>
So, what do people think, is this worth a go? I recognise this proposal makes<br>
a fairly large assumption, that lack of visibility is the problem to be<br>
solved. If the underlying problem is that not enough people have the time or<br>
willingness to review code, no amount of signal boosting is going to improve<br>
things.<br>
<br>
Thanks for reading,<br>
<br>
Alex<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'llvm-dev@lists.llvm.org')">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div>