<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 15, 2020 at 2:04 AM Doerfert, Johannes via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
I experience a fair share of problems when it comes to code reviews and<br>
change requests so I appreciate any improvement we can make here.<br>
<br>
<br>
On 01/14, Chris Lattner via llvm-dev wrote:<br>
> Numerous people have been bringing up challenges with consensus driven<br>
> decision making in the LLVM community. After considering this and<br>
> seeing the frustrations it is causing many people, I think we should<br>
> make a formal process change to help improve decision making going<br>
> forward.<br>
<br>
Improving is always a good idea.<br>
<br>
<br>
> Here is the outline of the draft proposal<br>
> <<a href="https://gist.github.com/lattner/e3679998a7609c99b1243f09d30f0132" rel="noreferrer" target="_blank">https://gist.github.com/lattner/e3679998a7609c99b1243f09d30f0132</a>>.<br>
> Caveats: this is itself just a draft proposal to inspire discussion<br>
> not a mandate - I welcome feedback, thoughts and concerns, ideas of<br>
> how to make this better, or better ideas/approaches overall on how we<br>
> can level up the community.<br>
> <br>
> Please let me know what you think, thanks!<br>
<br>
First thought: This should not be a gist on github. Maybe it should be<br>
on phabricator or at least in an email so it is easier to respond to it.<br>
<br>
<br>
I'll try to inline the gist below so I can respond to the points.<br>
<br>
---<br>
<br>
> "It isn't clear how to propose some changes in the first place, and it<br>
> is often unclear who the decision makers are."<br>
<br>
I feel that patches and RFCs are well established *and documented* [1,2]<br>
ways to propose changes. In addition, the *-dev lists, IRC, etc. do<br>
provide ways to clear uncertainties. Adding more documentation on this<br>
can obviously be helpful. Also, we are already improving the existing<br>
documentation [0].<br>
<br>
That said, we need to differentiate in more detail what the problems<br>
actually are. Do people not find the documentation? Is the documentation<br>
unclear? Are people waiting for "a decision maker" to step in or afraid<br>
to ask questions? Are questions not answered? ...<br>
<br>
<br>
> "It isn't clear what mailing lists to send such proposals to: llvm-dev<br>
> gets a lot of traffic and many people don’t read it."<br>
<br>
I argue that people that do participate in the decision making (wording<br>
took from the previous point) already do, or at least should, follow<br>
llvm-dev.<br>
I am not quite sure why it is unclear what mailing list is the right one<br>
given that we have one *-dev mailing list per subproject and on llvm-dev,<br>
often the first points-of-contact, people are referred to the right one.<br>
<br>
<br>
> "It is hard to know whether something is a serious proposal that you<br>
> must take seriously, and so it is easy to miss important changes<br>
> because you don't have time to review everything. Even though you<br>
> technically had a chance to participate, you can end up surprised when<br>
> some change goes into effect."<br>
<br>
I'm unsure what kinds of proposal are supposed to be "not serious" and<br>
who is supposed to be making that decision.<br>
<br>
<br>
> "Sometimes people chime in late with dissent after a decision has been<br>
> apparently made: this can be frustrating to people who need a decision<br>
> made, because they aren't sure how to proceed."<br>
<br>
It is unclear to me how the proposal helps on this front. Could you<br>
elaborate?<br>
<br>
<br>
> "Sometimes people express a loud voice on discussion threads even if<br>
> they aren't active contributors, and they can derail discussions.<br>
> There is no "moderator" for these discussions."<br>
<br>
With the caveat of finding the moderator (as mentioned below), this<br>
makes sense. We probably/hopefully don't need a moderator (for this<br>
reason) on many discussions but it might certainly help if people step<br>
up if a discussion is derailed (for any reason and by anyone).<br>
<br>
<br>
> "The initial discussion phase of a proposal can have lots of back and<br>
> forth discussions to shape a idea, and the eventual proposal can have<br>
> significant changes from that initial review. It can be difficult to<br>
> discern what feedback from the initial review is addressed or ignored<br>
> in the final rounds of discussions."<br>
<br>
Yes. I am not sure how the proposed solution remedies the problem<br>
though. Could you elaborate?<br>
<br>
<br>
> "Complex changes (e.g. the relicensing project) sometimes take many<br>
> rounds of iteration, and it can be easy to lose track of where the<br>
> proposal is and what the history was."<br>
<br>
This is certainly true. The proposed solution (with moderators and<br>
rounds) is probably implementable and reasonable for "complex changes".<br>
<br>
<br>
> "Occasionally, Code Owners may be faced with a technical decision and<br>
> not be sure what to do, particularly for highly impactful design<br>
> decisions - e.g. for core LLVM IR changes. It could be useful to have<br>
> a formal escalation process for these decisions."<br>
<br>
TBH, I always thought "code owner" is not a "decision making" but rather<br>
an "administrative" title. The person can be part of the decision<br>
making, but the role of "code owner" does not imply special privileges,<br>
only tasks, e.g., making sure reviews are done by the right people.<br>
<br>
<br>
> I recommend that we add a process similar to (but adapted and changed<br>
> where it makes sense) the Swift Evolution process. This process was<br>
> designed to help guide decision making for high impact language and<br>
> standard library changes to the Swift language. It was inspired by<br>
> similar processes in other language communities (e.g. the Rust<br>
> Language RFC process, the Python PEP process, etc) and has worked well<br>
> in that context - it stands to reason that a variant should work well<br>
> for LLVM as well.<br>
<br>
I tried to determine how Rust RFCs (and Python PEPs) influenced the<br>
proposed Swift Evolution process but from the history of the linked<br>
pages (in the gist) that was not clear. Could you elaborate on that?<br>
<br>
<br>
> The solution entails several parts. First, the process should be<br>
> written down!<br>
<br>
Agreed!<br>
<br>
<br>
> This written process should include things like:<br>
> <br>
> An informal "pitch" phase to help collect requirements and shape<br>
> the ultimate form of an idea, but which can be ignored by people<br>
> who aren't interested in following all of the details of a<br>
> discussion.<br>
<br>
How is this different form the discussion that happens after an initial<br>
RFC is send?<br>
<br>
People already ignore it if they are not interested in the details. If<br>
people chime in late, as mentioned in the problems above, this will not<br>
help, right? I mean, if the pitch phase is done and then people start to<br>
chime it starts again. This can have any reason, they are late, they<br>
want to see if it is really "a serious proposal", or they just want to<br>
wait until the first round of discussion changed the proposal to start<br>
the second round.<br>
<br>
<br>
> A new mailing list (or Discourse channel) dedicated to formal<br>
> proposal review. This would be relatively low volume, allowing<br>
> effectively everyone to follow it. This could be named something<br>
> like "llvm-proposals".<br>
<br>
1) We have already 30+* Discourse channels. Having so many, and one<br>
more, makes it harder to actually monitor them. Additionally, people<br>
that do not have Discourse are already excluded from the discussion.<br>
(I feel this had/has the opposite effect it was supposed to have.)<br></blockquote><div><br></div><div>Are you sure that you are not confusing <a href="https://llvm.discourse.group">Discourse</a> with Discord here?</div><div><br></div><div>Discord is an IRC replacement, Discourse is more of a candidate to replace the mailing-list (there is a mailing list mode where every post end up in your mailbox: it should not be a regression over the mailing-list).</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
2) Arguably you could filter *-dev lists for the tag RFC instead of<br>
having a new mailing list^. People sending RFCs send without the tag<br>
can be asked to send it again with the tag. <br>
3) This would only be low-volume if you do not count the<br>
responses/discussion.<br>
<br>
* I haven't counted them but I am probably close with my estimate.<br>
^ We have a lot already which can be, as implicit mentioned above,<br>
confusing.<br>
<br>
<br>
> A written proposal template, which provides guidelines for how to<br>
> write a proposal. This proposal is written in an example template<br>
> we can use, and the template can evolve over time.<br>
<br>
I'm in favor.<br>
<br>
<br>
> A new directory on Github that serves as the archive for official proposals.<br>
<br>
I don't see how that helps so I'd like to ask you to elaborate why this<br>
is not yet another place one has to look for information.<br>
<br>
<br>
> A review manager who helps shepherd the discussion in official<br>
> rounds of review (which are time bound, e.g. to a week or two).<br>
<br>
Could you elaborate on how these review managers are determined?<br>
<br>
<br>
> A decision making body that evaluates the results, asking for<br>
> additional discussions (with advice for how to change the proposal<br>
> in the next round), and that ultimately approves or denies a<br>
> proposal. This body should aim to get the community to consensus<br>
> whenever possible, but can help split decisions in the case of<br>
> extreme ambiguity when overwise all hope is lost. Denied proposals<br>
> can of course be re-run if a pertinent situation changes or when<br>
> revised<br>
<br>
Could you elaborate on how these "decision making bodies" are<br>
determined?<br>
<br>
<br>
Thanks for initiating this,<br>
Johannes<br>
<br>
<br>
[0] <a href="https://reviews.llvm.org/D71916" rel="noreferrer" target="_blank">https://reviews.llvm.org/D71916</a><br>
[1] <a href="http://llvm.org/docs/DeveloperPolicy.html#code-reviews" rel="noreferrer" target="_blank">http://llvm.org/docs/DeveloperPolicy.html#code-reviews</a><br>
[2] <a href="https://www.llvm.org/docs/Contributing.html" rel="noreferrer" target="_blank">https://www.llvm.org/docs/Contributing.html</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>