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

[Chris Tetreault via llvm-dev]

Chris,

   I am greatly in favor of having a process to elevate issues and settle contentious arguments once and for all. Throughout my career, I often see organizations get bogged down in arguments over the course of years, never solving anything because nobody is able/willing to “have the final say.”

   An assorted list of thoughts and feedback items:


  *   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 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 think that it would also be good to have all the subproject RFC’s in once place; more than once I’ve seen an RFC get cross-posted to llvm-dev, then tried to reply and got the “your message is being held for moderation” message because I’m not subscribed to flang-dev (or whatever mailing list). This might also have the side benefit of reducing noise on the subproject mailing lists if RFC’s are not posted (or cross posted) there.
  *   Once the process is settled, it might be a good idea to settle some contentious issues that have been argued on the mailing list recently. For instance, the issue of bumping the CMake minimum bound and API stability have been discussed on and off over the last 6 months, with no real resolution. I’m sure there are others that I haven’t noticed.
  *   From the FAQ: “Should we improve the existing LLVM RFC processes?” I think this would be a good idea. I think many RFC’s don’t really get discussed until patches start landing, which is really frustrating. If there were a process whereby RFC’s would be approved/denied, I think it would motivate people to pay more attention to them.
  *   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.
  *   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?

   Regardless, thanks for working on this issue!

Thank you,
   Christopher Tetreault


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Chris Lattner via llvm-dev
Sent: Monday, June 8, 2020 2:21 PM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] [PROPOSAL] Introduce a new LLVM process to resolve contentious decisions

Thank you to Mehdi and Kit for their feedback on this thread so far - I’d really love to hear from others in the community as well, even if it is a simple “+1 this sounds great” or “I’m concerned about XYZ specific aspect of this” or “-1, LLVM has no problems making decisions” :-)

-Chris


On Jun 2, 2020, at 1:19 PM, Chris Lattner <clattner at nondot.org<mailto:clattner at nondot.org>> wrote:

Hi all,

Following up on the extensive discussions since January, many of us would like to put in place a process to improve LLVM’s decision making process for contentious issues.  I’ve put together a proposal for how this works, and am recursively using it to get feedback on the process itself.  Thank you to the many people who contributed great ideas and improvements during the pitch phases and early drafts of the doc.

Because this is a weird case, I’m not setting up the standard review manager team for this.  We’ll wing it, and if it doesn’t work out, we can try again.

-Chris

——

Hello LLVM community,

The review of "Introduce a new LLVM process to resolve contentious decisions" begins now and runs through
June 12, 2020. The proposal is available online<https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md>.

Feedback is an important part of the LLVM Proposal process. All review feedback
should be either on this forum thread or, if you would like to keep your feedback
private, directly to one of the review managers.

**What goes into a review?**

The goal of the review process is to improve the proposal under review through
constructive criticism and, eventually, determine the direction of LLVM. When
writing your response, here are some questions you might want to answer in your
review:

*   What is your evaluation of the proposal?  What positive or negative
    implications would accepting this have?
*   Do you have experience from other communities that relates to this
    issue and is important to consider?
*   How involved have you been in the LLVM project?  Frequent contributor,
    occasional contributor, user of LLVM libraries, user of LLVM-based tools,
    or other?
*   Self Evaluation: How much effort did you put into your review and how
    knowledgeable are you about this area? For example, a quick reading or an
    in-depth study?

In addition to your opinion and thoughts, please include any additional
framing that may be useful.

Thank you,

Chris Lattner
Review Manager



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