[Mlir-commits] [mlir] [mlir] List lead maintainers for MLIR (PR #146928)

[Renato Golin]

rengolin wrote:

I'd like to bring some closure to this discussion, as it's clearly spinning in no clear direction.

This process has followed the standard LLVM process, that is documented and has been extensively discussed and approved by the community for the past few years. As exposed above by @ftynse, @AaronBallman and @matthias-springer, it has been well thought, with the best intentions, and closely following the process.

For clarity's sake, I may repeat some things that have already been said in this thread.

## Intent

_"Each top-level project in the monorepo will specify one or more lead maintainers who are responsible for ensuring community needs are met for that project."_

https://llvm.org/docs/DeveloperPolicy.html#maintainers

## Duty

_"area teams are responsible for maintaining an up-to-date and comprehensive list of maintainers for their area of the project."_

https://github.com/llvm/llvm-www/blob/main/proposals/LP0004-project-governance.md#area-teams

## Representation

The area team was voted by the community and three people were selected (Alex, Renato, Jacques), who unanimously agreed to bring Matthias (the fourth in number of votes) to the team.

https://discourse.llvm.org/t/llvm-area-team-election-results/84601
https://elections.llvm.org/app/elections/tmp---election---elections---2025---MLIR/results/

## Self-nominations

We have received 23 self-nominations and have sought many more for the dialects and areas that did not have self-nomination. We tried to follow the self-nomination to the most accurate interpretation, since the form was simple (to encourage responses).

As Matthias clarified, we have run searches through Github and Discourse to validate nominations (is the person really that active?) and to seek new nominations (who are the active people?) to complement that list.

_Note to Mehdi: Your nomination's literal request was "All but tensor compiler (linalg/TOSA/affine stuff)". That does not imply "catch all" nor "lead maintainer". We initially had you on both `core` and `egress`, but the `egress` area had too many people._

## Requirements

Following the agreed processes in LLVM for the past many years, it is expected that maintainers focus on _"consensus seeking"_, not in _"being individually convinced"_. To avoid bias, and to follow thoroughly agreed principle in the MLIR charter discussion, we decided to have multiple maintainers for _every_ part. This reduces contention and helps convert individual understanding into a group consensus.

Maintainers, especially lead maintainers, need to strictly follow the code of conduct. This is not some _"politically correct"_ requirement, but a crucial part of leading a community of vastly different cultures, expectations, roles and investment abilities. There should never be hypothesis of incompetence of others in maintainers' speech, or a requirement that a particular maintainer should be completely convinced of an argument for it to be a consensus.

https://github.com/llvm/llvm-www/blob/main/proposals/LP0001-LLVMDecisionMaking.md
https://github.com/llvm/llvm-www/blob/main/proposals/LP0004-project-governance.md
https://llvm.org/docs/CodeOfConduct.html

## Final Remarks

Throughout the process, we have talked to a lot of people in the community and kept communication with the project council on the process, the decisions and the rationale behind everything. The decision reflected in this PR has been validated by the council, accepted by everyone we spoke to, and unanimously agreed by the area team.

_Note to Mehdi: We may not have spoken to _everyone_, but that wasn't out of spite or careless, as some of your language seem to imply (even if through hypothesis), just out of time and need. We believe we have followed your request to the best of our abilities._

https://github.com/llvm/llvm-www/blob/main/proposals/LP0004-project-governance.md#project-council

https://github.com/llvm/llvm-project/pull/146928