| ================== |
| Project Governance |
| ================== |
| |
| .. contents:: |
| :local: |
| |
| |
| Area Teams |
| ========== |
| |
| Role and Responsibilities |
| ------------------------- |
| |
| *Area teams* have three main responsibilities. |
| |
| First, they are responsible for electing from among themselves a team secretary |
| who will take notes of any team meetings and a team chair who facilitates team |
| meetings and represents the team on the *project council*. |
| |
| Second, *area teams* are responsible for maintaining an up-to-date and |
| comprehensive list of maintainers for their area of the project. They can |
| nominate any individual they deem appropriate as maintainer of any area they |
| are responsible for. The role of maintainer remains a volunteer role, and any |
| individual can accept, decline, or resign the role for themselves as they feel |
| appropriate. |
| |
| Finally, *area teams* are responsible for facilitating decision making for |
| their area of the project. Facilitating decision making can take any number of |
| forms ranging from contributing to RFC discussions, helping mediate |
| disagreements. |
| |
| *Area teams* should prepare a meeting agenda by collecting all the active RFCs |
| in the community or significant disagreements in pull requests. During the team |
| meeting, the *area team* should try to identify actionable next steps or |
| information to gather so the RFC or pull request can proceed. An *area team* |
| may escalate to the *project council* as needed. |
| |
| When acting to facilitate decision making the *area team* should act as a |
| mediator between different perspectives helping find common ground and |
| recognizing that decisions need not be binary. The *area team* should seek to |
| find the best solution to the framed problem, which may not be any of the |
| proposed alternatives. If agreement cannot be reached, the *area team* may act |
| as the final decision maker. In that capacity decisions of an *area team* are |
| considered final, but can be overruled by a 2/3 majority vote of the project |
| council or the *area team* itself revisiting the issue. If an *area team* |
| cannot reach consensus, it may request the *project council* to resolve the |
| disagreement. |
| |
| A fast "no" is often a better outcome than an indefinite "maybe". In |
| recognition of that, an area team, when acting as the facilitator of decision |
| making, will publicly communicate a timeline for discussion and decision |
| making. The *area team* will communicate when a topic is on the agenda for a |
| meeting with sufficient notice for relevant parties to participate. |
| |
| *Area teams* are not intended to be direction setters or primary maintainers of |
| their areas, although individuals on an *area team* may fulfill that role |
| separately. The area team's role is as a steward and moderator ensuring the |
| health and smooth operation of the area. |
| |
| Elections and Composition |
| ------------------------- |
| |
| To be a *voting contributor* an individual must be a member of the LLVM GitHub |
| Organization, and either have a public email address on their GitHub profile or |
| have made a commit to the LLVM project using a non-private email address. The |
| email address on the GitHub public profile or retrieved via commit metadata |
| will be used for all election-related communication. |
| |
| Each *area team* will have an odd number of members with a minimum of three (3) |
| members and a maximum of nine (9) elected by the *voting contributors*. |
| Candidates for *area teams* must be a voting contributor and self-nominated. An |
| individual cannot serve on two *area teams*. Members of an *area team* are |
| elected for 1 year terms. |
| |
| An *area team* with less than nine members may increase its size up to nine |
| members with a majority vote. The *area team* may then appoint members to fill |
| any vacancies as normal. If at the beginning of an election there are |
| insufficient candidates to fill all vacancies on an area team, the team size |
| will decrease to the largest odd number that all the candidates can fill. If |
| less than three candidates run for election for an *area team* the project |
| council will either recruit members or disband the team. |
| |
| The *area team* will take an active role in identifying potential candidates to |
| join the *area team* in future terms. In this capacity, the *area team* should |
| keep a focus on growth and development of contributors in the community, and |
| the community values promoting diversity and inclusivity. |
| |
| Elections for area teams occur in January of each year. A two week long |
| nomination period begins the second Monday in January. During the nomination |
| period any *voting contributor* can nominate themselves or another *voting |
| contributor* to run for any one area team. No individual can run for more than |
| one area team in a single election. An individual nominated for more than one |
| area team will be responsible for choosing which team they want to run for. |
| Nominations will be recorded publicly for community visibility. Unsuccessful |
| results in an election do not impact nomination eligibility in subsequent |
| elections. |
| |
| Voting begins the fourth Monday in January and continues for 2 weeks. Election |
| results will be announced no later than two days after voting closes. The term |
| of the newly elected area team begins the first Monday in March. Each area team |
| will meet during the first week in March to elect from themselves the team |
| secretary and chair to re-constitute the project council. |
| |
| Vacancies |
| --------- |
| |
| A member of an *area team* can resign at any time. As life can sometimes happen |
| unexpectedly, a member of an *area team* may be unable to fulfill their duties or |
| resign. In that case, a majority of the remaining *area team* may vote to declare |
| the member removed in absentia after a 90-day absence. |
| |
| If someone resigns or is otherwise removed from an *area team*, the remaining |
| members of the *area team* may appoint a replacement to serve the remainder of |
| the term through any process they choose. |
| |
| Active Area Teams |
| ----------------- |
| |
| There are currently four *area teams*: |
| |
| * **LLVM** - Covering ``llvm`` source area. |
| * **Clang** - Covering ``clang`` source area. |
| * **MLIR** - Covering ``mlir`` source area. |
| * **Infrastructure** - Covering project-wide automation and other infrastructure. |
| |
| |
| Project Council |
| =============== |
| |
| Role and Responsibilities |
| ------------------------- |
| |
| The *project council* is composed of the chair from each of the *area teams*. |
| |
| The *project council* has a mandate to: |
| |
| * Prioritize the long term health of the LLVM project and community. |
| * Shape the community to be accessible, inclusive, and sustainable. |
| * Maintain the relationship between the LLVM Community and the LLVM Foundation. |
| * Assist *area teams* in identifying and growing community leaders. |
| * Facilitate seeking consensus among the LLVM Community and *area teams*. |
| * Act as, or delegate to, an *area team* for all issues that are not covered by an area team, or span across multiple project areas. |
| * As a last resort, act as the final decision maker on debates. |
| |
| The *project council* will elect from among themselves a secretary who will |
| take notes of all meetings, a chair who facilitates meetings, and a liaison to |
| the LLVM Foundation to manage the relationship between the *project council* |
| and the LLVM Foundation. |
| |
| Representatives to the *project council* are also term limited. An individual |
| may not serve on the *project council* for more than two consecutive terms. |
| This limit may also be waived by the *project council* if and only if the |
| respective team is unable to produce a different representative. |
| |
| The *project council* has the power to form and dissolve *area teams*. Forming |
| an *area team* requires a majority vote. Any changes to the *area team* |
| structures must be publicly disclosed including the motivation for the changes. |
| Dissolving an area team, or altering the boundaries of an *area team* requires |
| a consenting vote of the chair of the area team(s) being altered and a majority |
| vote of the *project council*. |
| |
| |
| Governance Meetings |
| =================== |
| |
| Each *area team* and the *project council* should have scheduled public |
| meetings. The date of the scheduled meetings should be on the LLVM Community |
| Calendar. The calendar invite will have a link to a public meeting agenda. The |
| teams may have non-public meetings for discussion, deliberation, planning or |
| other purposes. The team may cancel a meeting if no items are on the agenda or |
| to accommodate member schedules (holidays, personal time, etc). |
| |
| Notes from all *area team* and *project council* meetings will be publicly |
| posted. Notes will exclude reference to any private information, or information |
| that otherwise needs to be confidential. |
| |
| |
| Current Composition (2026) |
| ========================== |
| |
| Project Council |
| --------------- |
| |
| * **Chair:** Aaron Ballman (@AaronBallman) - representing Clang |
| * **Secretary:** Alex Zinenko (@ftynse) - representing MLIR |
| * **Members:** |
| |
| * Nikita Popov (@nikic) - representing LLVM |
| * Reid Kleckner (@rnk) - representing Infrastructure |
| |
| Area Teams |
| ---------- |
| |
| * **LLVM Area Team** |
| |
| * Nikita Popov (**Chair**) |
| * Matt Arsenault |
| * Florian Hahn |
| |
| * **Clang Area Team** |
| |
| * Aaron Ballman (**Chair**) |
| * Eli Friedman |
| * Erich Keane |
| * Corentin Jabot |
| * Shafik Yaghmour |
| |
| * **MLIR Area Team** |
| |
| * Alex Zinenko (**Chair**) |
| * Renato Golin |
| * Matthias Springer |
| |
| * **Infrastructure Area Team** |
| |
| * Reid Kleckner (**Chair**) |
| * Petr Hosek |
| * David Blaikie |
| |
| |
| Meetings and Contact Information |
| ================================ |
| |
| Project Council |
| --------------- |
| * **Meetings:** First Wednesday of each month at 9:00 AM PT / 4:00 PM UTC / 6:00 PM CET. |
| * **Contact:** Tag `@project-council` on `LLVM Discourse <https://discourse.llvm.org/>`_. |
| |
| Area Teams |
| ---------- |
| |
| * **LLVM Area Team** |
| |
| * **Meetings:** Bi-weekly on Wednesdays at 16:00-17:00 CET. |
| * **Contact:** Tag `@llvm-area-team` on `LLVM Discourse <https://discourse.llvm.org/>`_. |
| |
| * **Clang Area Team** |
| |
| * **Meetings:** Closed administrative meeting bi-weekly on Thursdays at 10:00 AM PT. Open meetings are scheduled flexibly. |
| * **Contact:** Tag `@clang-area-team` on `LLVM Discourse <https://discourse.llvm.org/>`_. |
| |
| * **MLIR Area Team** |
| |
| * **Meetings:** Announced on Discourse (not regularly scheduled at a fixed interval). |
| * **Contact:** Tag `@mlir-area-team` on `LLVM Discourse <https://discourse.llvm.org/>`_. |
| |
| * **Infrastructure Area Team** |
| |
| * **Meetings:** Bi-weekly on Thursdays at 9:30 AM PT. |
| * **Contact:** Tag `@infrastructure-area-team` on `LLVM Discourse <https://discourse.llvm.org/>`_. |
| |
| All meetings are listed on the `LLVM Community Calendar <https://calendar.google.com/calendar/u/0/embed?src=calendar@llvm.org>`_. |