<div dir="ltr"><div>To be clear, my comment was purely intended to refer to non-technical decisions (i.e. not things like code reviews etc that stall because there's disagreement about what to do, but rather things like switching to the monorepo/github PRs etc). Indeed, my understanding from Chris's pitch is that his proposal isn't intended to address that either:</div><div><br></div><div>"
One note: While there are challenges with patch review and code owners, 
this proposal focuses on non-technical decisions that do not have a 
clear "code owner" escalation path today.  This can include things like 
the introduction of new subprojects, introduction of a new social 
policies, change to core infrastructure like bug review tools or patch 
review processes, changes to the LLVM Developer Policy, etc."</div><div><br></div><div>These decisions are significantly more impacting than the more technical ones as they usually impact pretty much every single developer. They are also often irreversible after a certain point, or at least would cause serious issues if we tried to reverse. Finally, once a decision has been made and started to be implemented, I always feel like there's a greater level required for objections, so people who weren't able to be involved are less likely to voice their opinions after the fact in a way that will actually generate any further discussion. Don't get me wrong, I agree that we can't keep a review open forever, since you can't accommodate everyone (e.g. months-long parental leave/long-term sicknesses/sabbaticals etc), but surely 1-2 weeks for such decisions isn't enough.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 15 Jan 2020 at 10:18, Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov">jdoerfert@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 01/15, James Henderson via llvm-dev wrote:<br>
> One other thought: any formal review period needs to be long enough for<br>
> people to contribute to if they have any annual leave from work or<br>
> whatever. For example, if the review period were to be set to two weeks,<br>
> I'd have missed proposals made at the start of roughly 2-3 different 2 week<br>
> periods last year. It would have been worse for 1 week. On the other hand,<br>
> a 3 week period would have meant I'd be able to read and respond to every<br>
> review. Note this is just an example - I'm not concretely suggesting 3<br>
> weeks; perhaps it should be longer for bigger changes etc?<br>
<br>
There are various opinions on this (see for example the discussion here<br>
[0]).<br>
<br>
My take is that there is no fixed reasonable time to review and respond.<br>
There is a minimal one, due to weekends and time zones, but as soon as<br>
we take vacation/trips into account the problem is unbounded. Instead, I<br>
argue that post-reviews and potential revers are acceptable. If a<br>
consensus was reached and a reasonable* amount of time has passed<br>
changes should make it into the repository to guarantee timely progress<br>
for contributors. If problems are encountered later, either because the<br>
change was not on someones radar or because no one anticipated some<br>
problematic interaction, we should be flexible. A post-review discussion<br>
is appropriate if improvements are needed, a potential revert and<br>
follow-up review are appropriate if it was an actual breaking change.<br>
<br>
<br>
* Both "consensus" and "reasonable amount of time" are arguably<br>
  vague here. Appropriate metrics depend on the impact of the proposed<br>
  change and written guidelines would be helpful [1].<br>
<br>
<br>
[0] <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-November/136808.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-November/136808.html</a><br>
[1] <a href="https://reviews.llvm.org/D71916" rel="noreferrer" target="_blank">https://reviews.llvm.org/D71916</a><br>
</blockquote></div>