Last year at the US LLVM Developer Meeting we presented a proposal for adopting a project governance model for LLVM. The proposal was reviewed extensively in a PR, and discussed at EuroLLVM last spring.
The proposal has evolved over the year, and as we look to this year’s US LLVM Developer Meeting we’re working to move the proposal forward. Our main goal over the next month or two is to reach a proposal and consensus to try it.
Below is an (extremely brief) summary of some of the key points of the proposal, and a few concrete details for the next steps. We’d like to ask the community to review and provide any additional feedback.
@dblaikie, @ldionne, @cishida, and @tstellar have volunteered to act as review managers to help collect feedback and refine the proposal.
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.
Area teams have three main responsibilities:
- Electing a secretary and chair. The chair represents the area team on the project council.
- Maintaining an up-to-date and comprehensive list of code owners for their areas of the project.
- 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.
First Elections
The proposal documents performing elections through Concordcet Internet Voting Service, which is the service used by Python’s governance. A comment on the PR suggested Elekto, however Elekto seems to be abandoned with no active development in the last year. We propose that we move forward with Concordcet for the first election and see how it goes. We propose conducting our first elections in January 2025.
Voter Registration
There was a recent discussion about GitHub’s private emails. This resulted in @AaronBallman posting a PR last week updating the developer policy to reflect that we require public email addresses for contributors.
With this policy, we can base voter registration completely on membership in the GitHub LLVM organization, and no explicit registration is required from users as long as either:
- the user has a public email address on their profile, or
- the user has either authored or committed a change to a repository in the LLVM organization using their GitHub account.
If the proposal is adopted, in addition to the notifications included in the proposal, for the first election additional notifications will be provided to help ensure full voter registration. Thirty days before the election, we will use scripts to register all eligible voters by using GitHub profiles or commit metadata to identify email addresses. All automatically registered voters will receive an email notifying them that they have been registered. After the notification emails are sent, a post will be made to Discourse to notify users that the notifications have been sent, and it will provide a contact for any user who did not receive a notification but believes they should have.