Clang Area Team Initial Communication

The Clang Area Team (@AaronBallman, @rnk, and @efriedma-quic) had our first meetings (Feb 20 and Mar 06) to organize the team and the work we’ll be doing and we wanted to share those details with the wider Clang community. Our meeting notes can be found at https://docs.google.com/document/d/13-68BCOt8kH5k_56fURBi7u7Ap97Z0EshgkJXDudbJM

High Level

We decided to keep the area team to three people for right now, but will be open to expanding the team if we think that will help the process. @AaronBallman will be the chair and will represent Clang on the Project Council. @rnk will be the secretary and will take meeting minutes and populate the agenda for meetings.

Our plan is to hold alternating meetings twice a month (four meetings in total), which will be listed on the Community Calendar (Getting Involved — LLVM 21.0.0git documentation). Our primary goal is to provide feedback to proposal authors so they understand what their next steps are (how to increase consensus on a proposal, whether a proposal is accepted or rejected, etc) in a timely manner. We’re aiming to ensure RFC authors get this feedback within two weeks of a request to the Clang Area Team, but there’s currently no SLA because we’re not certain how heavy the workload will be.

Lower Level

As mentioned, we’re holding alternating meetings. The first meeting is open to the whole community and we will explicitly invite RFC proposal authors and maintainers or other relevant parties based on the agenda. The goal of this meeting is to discuss the issues raised on the RFC, give a chance for real time discussion on the topic, and try to resolve misunderstandings.

The second meeting is closed to the community and will be where the Clang Area Team codifies what feedback to give to the proposal authors to let them know their next steps and to post that feedback to the Discourse thread for the RFC. The “interesting” work is expected to happen at the first (open) meeting; the second (closed) meeting is more for administrative purposes so that we maximize the amount of time spent on proposals discussed by the community in the first meeting.

The second meeting is held on a regular cadence, thirty minutes on Thur @ 10am PT every two weeks. This ensures the community and RFC authors have some predictability in terms of when to expect feedback. The first meeting will be scheduled earlier that week, but the date and time will be flexible so that we can ensure the critical parties can all attend. We will post in the RFC when this meeting will be held so that everyone involved on the thread is aware without needing to check the community calendar manually. These meetings will be held via a stable Google Meet link which will be available in the community calendar. As always, these meetings will be governed by the LLVM Community Code of Conduct (https://llvm.org/docs/CodeOfConduct.html).

Process

The RFC process is not being drastically changed. Authors will continue to write their proposals on Discourse (please remember to add [RFC] to the post title) and proposals which have obvious consensus (for or against) will not need to be seen by the area team. However, the Clang Area Team secretary will proactively look for RFCs that appear to not have a clear path forward to add them to the team’s agenda. Also, if someone would like to put an RFC onto the team’s agenda explicitly, they can tag any one of the Clang Area Team members in a comment on the RFC to get our attention.

We will fill our agenda roughly in chronological order, but there may be juggling of proposals based on availability of proposal authors and other necessary participants. Aside from the Clang Area Team members and proposal author, nobody is required to attend these meetings. However, if we reach out to you asking for your participation, your attendance would be greatly appreciated.

The Clang Area Team will meet soon after the RFC discussion to determine what feedback to provide and will post that feedback to the RFC on Discourse. Note, sometimes that feedback may be “here are ways to increase consensus, please continue the discussion in community”, “we want the community to continue discussion before we schedule an open community meeting to discuss it”, or “we want the proposal to be seen by another area team as well”. The goal is not to make final decisions every two weeks, it’s to facilitate building community consensus around a proposal and that sometimes takes multiple iterations.

Secondary Objectives

The Clang Area team is ultimately responsible for the health of the Clang project as a whole. As such, we are tasking ourselves with the following activities:

  • Governance is a new process in the community and there’s no reason to believe it’s perfect on the first try. We will be flexible and change the Clang Area Team process as we discover better ways to work, and that will be based both on how things are working for us and how things are working for the community. We will document potential changes to the governance process and policies and aim to provide this feedback to the community in the early Fall, before the next election cycle.

  • Keeping the maintainers list up to date. Specifically, ensuring inactive maintainers are removed and helping to identify new maintainers to nominate.

  • Documenting Clang community policies. Clang has a lot of de facto policies we’ve never written down and we aim to start writing those down. Note, these policies will go through the usual RFC process, same as any other policy decision.

  • Periodically reviewing existing policies to see if adjustments are warranted. Again, any non-editorial adjustments will go through the usual RFC process.

7 Likes

Thank you for writing this up - I’m really looking forward to see how this works out. The clarification about how this interacts with the RFC process we’ve used to date is particularly helpful.

I think the access permissions are wrong on this - I can’t access without explicitly requesting permission.

1 Like

Thanks for letting me know, please try again – the permissions should be fixed now.

1 Like

This sounds nice, thank you! Happy to join RFC related discussions - I see ClangIR mentioned in the notes :slight_smile:

1 Like

It would be great if the meeting notes were stored in GitHub in the event that something happens to anyone currently on the core team and access is lost.
Alternatively, the LLVM Foundation can host documents on Google and retain access in the event anyone disappears. Let me know if you prefer that.

1 Like

Rust created one repository for each governing body (leadership-council, lang-team, etc).

This gives each team a place to store documents like meeting minutes as well as public issue tracking.

This might be a useful approach.

I am looking forward to seeing this process in action!