Hello all!
Apologies for not providing more regular updates. The end of 2023 was a busy time for me and I’ve just managed to catch up to responding to feedback.
Updates!
Since the original post I’ve posted updates to the governance proposal.
Most of the updates have been minor. Those include fixing errors (grammar, spelling or formatting), rewording for clarifications, or other small tweaks based on feedback.
Some of the more significant changes I’ve made are:
- Added language to stress that the role and process for nominating code owners is unchanged. Code owners play a vital role in LLVM which is essential to the project and the proposal does not try to alter that role.
- Added a section encouraging the use of the proposal process and providing a framework to help guide when to use the proposal process instead of LLVM’s informal RFC process.
- Split LLDB out into its own area team separate from the binary tools.
- Added requirements for governance team meetings.
- Removed mandatory voting.
Next Steps
The bigger issue that I see coming is once we’re happy (for some definition of “we” and some definition of “happy”) with a proposal, how do we as a community decide to adopt it.
My inclination is to rely on the Decision Making Process, which is why I wrote this as a proposal rather than an RFC at the outset.
I think there is still a fair amount of work to do on the proposal before we will be in a position to make a decision whether or not to adopt it. I expect most of that work will be tweaking important details (term lengths and limits, team responsibilities, voting rights, election structure, other meaty bits), and I think we’ll need active engagement and discussion.
I propose we take the following steps:
Identify review managers for the proposal
According to LP-0001 we need 2 or 4 review managers. I think that because of the scope of this proposal we need at least 4 and I can see an argument that we may need more than 4 to get enough diversity of perspective.
Public meetings for feedback
After the review managers are selected I want to hold a series of public meetings to collect feedback. I’d like to schedule those meetings at different times of the day to accommodate our geographical distribution and allow for smaller discussions. The public meetings should also occur in at least two waves. One early, and one with the near-final proposal before it goes for the final review discussion.
Define some deadlines
I don’t think I’m alone in wanting to see forward progress here so I’d like to try and define a schedule and some deadlines. The review managers will need to be involved in really setting a schedule for this but I’d like to see something like:
- March 1, 2024 - Review Managers Selected
- March 15, 2024 - Initial feedback from @clattner and Review Managers due.
- April 5, 2024 - Updated proposal due before EuroLLVM.
- May 3, 2024 - Completed a meeting with @clattner and Review Managers to define next steps.
@clattner and the review managers will approve any schedule.
Implementation
Pending on approval through the proposal process I would like to propose a goal that we have our first elections in August or September 2024 rather than waiting until January 2025, and that we skip the January 2025 election granting a slightly longer term to the first area team members.
I believe this adjustment for the first year will allow us to implement the proposal more quickly, and allow us to use the 2024 US LLVM Developer meeting as a venue for early collaboration.
Questions for the Community
- Do my proposed next steps sound reasonable?
- How should we select review managers?
- Are there any other proposals we should consider?
- What else am I missing?
