[llvm-dev] [PROPOSAL] Introduce a new LLVM process to resolve contentious decisions

[Chris Lattner via llvm-dev]

Than you all for the feedback, I’m responding to several selected comments in one email with my “proposal author” hat on:

> On Jun 8, 2020, at 3:35 PM, Robinson, Paul <paul.robinson at sony.com> wrote:
> fine.  Two specific comments:
> Still seeing a reference to discourse (last para of Proposed Solution, after item 9).  Thought that should be gone?

Thank you Paul, yes that was a mistake - I corrected this in the writeup.
 
> 
> As an aside, I noticed a use of the term “core LLVM contributor” which is not a defined role in this project.  

The intention wasn’t to introduce a new term here, just to make an observation that happens in practice.  I’d be happy to change this if you’d like to suggest different wording (or you can directly edit the writing yourself).  Thanks!


> On Jun 8, 2020, at 4:03 PM, Krzysztof Parzyszek <kparzysz at quicinc.com> wrote:
>  
> On a different note..  On more than one occasion, there would be disagreements regarding the interpretation of the official project policies.  In the specific cases I remember they related to the downstream/out-of-tree projects.  Person A would say “this affects OOT projects”, while person B would say “we should have no concerns about what’s not in tree”.  What consequences do you see coming out of resolving these controversies?  Would they be “precedents” for the purposes of interpretation of policies?

Yes, I generally consider this process to establish “case law”, where decisions and rationale can be referred back to to help inform future discussions.  Nothing is iron clad and immutable though - if we made a decision and it turns out to be wrong or should change in the future, then we should do so.

On Jun 8, 2020, at 4:04 PM, Eli Friedman <efriedma at quicinc.com> wrote:
> The proposal says “A group of either 2 or 4 community members are selected”; the document doesn’t really make it clear who selects them.  Reading it a few more times, it sounds like the process is supposed to be “The person writing the [PITCH] selects […]” (and then Chris can suggest adjustments)?  Is the person writing the [PITCH] allowed to be a review manager?


This is one of the areas that I’m also unclear about.  My sense is that someone coming up with a proposal that happens to be contentious will know who the stakeholders are on the “opposition side” because they’ve been the most engaged.  I believe that people act in good nature and will do the right thing by suggesting the right people to include, and so it makes sense for the initial proposed list to come with them.  This is a “trust but verify” style approach.

However, if this doesn’t work well over time, we can definitely change it!

> On Jun 8, 2020, at 5:08 PM, Chris Tetreault <ctetreau at quicinc.com> wrote:
> 
> 2 weeks might be a bit short of a discussion period for major policy changes. Many people go on vacation for that amount of time, and it would be unfortunate to come back from vacation and find that some major decision went in while you were out.


I don’t think there is any right amount of time to solve this problem, and extending out to 4 weeks or longer would just lead to unnecessary delays.   We should use common sense with this - what I’ve seen happen in the Swift community is some dynamic adaptation.  Proposals that need more time get extensions as needed.

> I think a separate mailing list would be good for these. RFC’s should also go into this new mailing list, so people who are too busy to follow [whatever]-dev can at least keep up to date on the RFC’s mailing list. 

I agree about this as well, and several others raised this.  However, I think we should tackle this as a follow-on discussion given the possible move to discourse.

> From reading the pitch, it sounds like the person drafting the pitch is responsible for nominating the 2-4 review managers. Assuming I understand this correctly, I think there are a few issues with this: 1) It might create a conflict of interests. The person drafting the pitch obviously wants it to go their way. They may attempt to (either unconsciously, or consciously), “stack the panel” with people sympathetic to their cause. 2) Similar to how it can be hard to pick code reviewers, it can be hard to know who to pick for the panel. This issue is especially true for new contributors who don’t know all the major players. It might be nice if there were an impartial third party responsible for picking the panel.

I agree with your concerns, but I think this is still a reasonable starting point - see the comment above.  I don’t think a third party will make it necessarily easier, and an obviously incorrect panel can be objected to by the community.

> In a previous round, you posted a google doc instead of a static page in github. I liked this because it allowed for inline comments to be posted and addressed. I think this would be a better format for discussing specific proposals than the mailing lists. If not a google doc (since it’s hard to do versioning there), then perhaps as a phabricator diff, or github PR?

I also agree that google docs are a much better way to do collaborative editing, and I’d encourage people to use them (or any other approach proposal authors prefer) in the drafting / pitch phase of the conversation.  However, when the conversation gets “official”, moving to a checked in page has significant advantages - including full versioning, linkability to any revision etc.

> On Jun 10, 2020, at 12:49 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> The proposal does not at all address the problem of total silence.
> Some RFCs just don't receive any response, and then people are
> uncertain about what that means. Silent agreement? Don't care?

My sense is that this won’t be a problem if we use the process on controversial proposals.  LP-0001 is mostly a clear cut case, which is why the traffic is low.  I expect something like “should we move to discourse” to generate a lot more discussion.  If it does turn out that a proposal gets insufficient feedback then we can deal with it contextually based on the details of the situation.

On Jun 10, 2020, at 1:34 PM, Philip Reames <listmail at philipreames.com> wrote:
> 4) I think it needs to be very clear that reviewers are only expected to have read the current proposal.  It should be the responsibility of author to summarize previous discussion.  I consider the "this was discussed in X old thread" an anti pattern for this type of discussion.


Yes, I completely agree - the purpose of the review process if for the discussion to be self contained - people should not be required to follow the RFC/Pitch phase of the conversation.  If this is unclear in the writing, can you propose an improvement?

Thank you all for the feedback!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200614/288f4b69/attachment.html>