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

[Mehdi Amini]

joker-eph wrote:

As mentioned earlier, I believe we should prioritize individuals with a substantial and broad track record of involvement across the project—particularly within core components. This includes contributions spanning architecture, diverse technical areas, and long-term impact.

In my view, a lead maintainer is not primarily a deep expert in a single area (we already have component maintainers for that), but rather someone with system-level expertise. They should be capable of working across components and bringing together the right people when needed.

Naturally, this isn't just about code. Rigid metrics—such as requiring a specific number of commits—are not, in my opinion, appropriate. We should evaluate the full spectrum of contributions: code, reviews, design discussions, RFCs, LLVM Developer Meeting talks, and more. That said, there's a meaningful distinction between a newcomer with ten commits in a narrow area and someone with hundreds across the project. While not definitive, such data points can help frame the conversation. We should absolutely expect a range of valuable profiles, including those with fewer code contributions but strong involvement in design proposals, architecture discussions, and review activity.

It might also be useful to ask each nominee to submit a brief "elevator pitch" outlining their contributions (both technical and non-technical), track record, and their vision for their role within the project.
In addition, individual nominations should likely be submitted as separate PRs. Handling nominations as a bundled list feels awkward and makes thoughtful evaluation more difficult.

Maybe we should ask each nomination to come along with some "elevator pitch" from the candidates, exposing their perceived contributions and track record  (code and others), how they see their role in the project. 

In addition, individual nominations should likely be submitted as separate PRs. Handling nominations as a bundled list feels awkward and makes thoughtful evaluation more difficult. It's already hard to have to discuss a single nomination, but picking apart a list seems like a terrible way to handle it IMO.

Of course, this process is much easier in a steady state. When a project already has established maintainers, there's a clearer understanding of what kinds of profiles and contributions lead to that role. Contributors can grow into the position by following these examples. As someone put it to me offline, you kind of get into a natural “you’ll know it when you see it.” 
I recall, over a decade ago, looking up to many LLVM code owners as role models during my early involvement in the project.

Precedent has always played an important role in keeping the project fair by applying consistent standards to all contributors. In this case, we are setting the very first precedents, and that’s all the more reason to move thoughtfully and perhaps more conservatively in our criteria for these initial nominations.

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