[RFC] LLVM Project Governance - October 2024 Update

LLVM Project
1

Hello LLVM community members!

Today we organized and held a proposal review call for the LLVM governance proposal, LP0004. We did not yet reach an outcome of “Approval” or “Approval with changes”, but we identified next steps below. I plan to schedule a follow up call, ideally this Friday ahead of the dev meeting so that we can approve it ahead of the event and talk about implementation at the dev meeting.

I’m sharing the mostly unedited notes from the meeting below for transparency. None of the statements, suggestions, or ideas below are final, but it gives you some idea what the review managers were thinking about.

Agenda

  • Recap the proposal (see summary)
  • Identify community concerns from PR comments and RFC threads and decide if
    they’ve been adequately addressed
  • Determine the outcome: Approve, Deny, Approve with Changes

Summary of the Proposal

The current proposal seeks to form 5 elected area
teams. The 5 area teams represent 3 of the most active
development areas in the project, as well as teams to represent infrastructure
and community:

  • LLVM
  • Clang
  • MLIR
  • Infrastructure
  • Community

Area teams have a minimum of three members and have three main
responsibilities:

  1. Electing a secretary and chair. The chair represents the area team on the
    project council.
  2. Maintaining an up-to-date and comprehensive list of code owners for their
    areas of the project.
  3. Facilitating decision making for their area of the project.

The project council, will act primarily as a body for
oversight, but will, as a last resort, act as the final decision maker.

Each of the governance bodies will have regular meetings open to the
community, with published meeting minutes.

Community concerns

  • We reduced the number of area teams considerably based on community feedback
    around bureaucracy, start small, grow. Based on post-EuroLLVM feedback.
    • Questions around where things fit: runtimes, libc++, compiler-rt, bolt, lld,
      etc
    • Initial area team choice was driven by RFC volume.
      • Can always escalate to project council. Project council should have no gaps:
        be able to have input on all decision making and know when to delegate, to
        area teams,
    • Starting up a new area team does not require waiting for elections,
      it’s easy and lightweight
  • Goal is good enough, not perfection. Launch and learn. Update.
  • Reid: Does facilitating decision making mean calling consensus on RFCs?
    Providing timely updates based on meeting cadence?
    • Some agreement about providing updates on RFCs after each area team meeting
    • Goal: Avoid languishing RFCs with no updates
  • Louis: What is driving the bimonthly meeting cadence?
    • Desire to have timely feedback, cover possibility for back and forth. Too
      many RFCs/month to do in a 1hr call.
    • Also want to avoid volunteer overload. Always have the option to cancel.
  • Tenure / term limits: Removed from area teams, but there is a desire to cycle
    the project council.
    • Removed for now, revisit in the future.
  • Voting
    • Details deserve clarification
    • Current state is all github org members who have made a contribution
    • Culling active contributors means we can just use org membership
    • Voting ballots will be sent by email, so we need policy and means to
      translate from github user id to email
      • Need to use org write access if we want to collect active contributors
    • Tom likes the foundation registry idea. Chris had concerns around github
      account ownership validation. Org membership intended to simplify things.
      • Crux of the issue is that we have no way to directly message github accounts
        with private emails
      • We can publicly message everyone through github issue ccs, which is
        already how we retire commit access rights
  • Should we time limit the proposal? A 1 year experimental limit was suggested. A
    provisional trial.

    • Produce a reflection on it ahead of the next US dev meeting in the fall 2025

    • Our community is technically focused and minded, most folks are heads down
      not focused on governance. Capturing their input in a year would be good.

    • “Provisional adoption” wording

    • We are deciding on this proposal now, we’re just building in a feedback
      mechanism

Resources

Next steps

  • Have review managers approve the PR as a draft, we’ll merge it, and send more PRs to resolve the AIs
  • Publish updated schedule
    • Consider that we are aiming for elections in January and the dev meeting is
      next Tuesday
  • Will schedule second call on Friday after making updates to LP0004 so we can
    try to get to a decision to adopt the proposal

Action items

  • Agree we should prefer “maintainer” over “code owner”
  • Update proposal to clarify that all issues bubble up to project council
  • Look into incorporating RFCs into the default area team agenda
  • Chris will update voting requirements
  • Codify how we plan to update and iterate on the process ahead of the next dev
    meeting
4 Likes
2

I’ve posted a new PR with updates to the proposal document based on the discussion with the review managers. The new PR is: Updates based on review manager meeting by llvm-beanz · Pull Request #84 · llvm/llvm-www · GitHub

3

Hi folks - qq: is there one place we can see how the governance next steps unfold? I’ve read the proposal and keep half an eye on these topics in the forums but it is hard to keep in mind without digesting all of the context (I’m asking because I just got an email to register to vote and went looking for updated info)?

(Thank you for doing this hard and necessary work: I’m purely asking for a procedural update, not contesting anything)

4

There’s a timeline in the proposal (llvm-www/proposals/LP0004-project-governance.md at main · llvm/llvm-www · GitHub).

I’ve fallen a few days behind schedule, but I should be back on track next week, and be ready with a second test email on Monday.

1 Like