[mlir] List lead maintainers for MLIR #146928
Conversation
Historically, MLIR project has not had a public list of maintainers, unlike the rest of the LLVM project and at odds with the developer policy. The MLIR Area Team initiated a process for (self-)nomination of maintainers in order to remedy this, and is now proposing to establish this list. Following the self-nominations, discussions in the MLIR Area Team and the LLVM Project Council, this is a proposed list of lead maintainers for the MLIR Project. The full list of maintainers expected for MLIR components and nomination criteria are available at https://discourse.llvm.org/t/mlir-project-maintainers/87189. These will be listed in the repo progressively.
ftynse
requested review from
nikic,
petrhosek,
jpienaar,
rengolin,
matthias-springer and
AaronBallman
|
@llvm/pr-subscribers-mlir Author: Oleksandr "Alex" Zinenko (ftynse) ChangesHistorically, MLIR project has not had a public list of maintainers, unlike the rest of the LLVM project and at odds with the developer policy. The MLIR Area Team initiated a process for (self-)nomination of maintainers in order to remedy this, and is now proposing to establish this list. Following the self-nominations, discussions in the MLIR Area Team and the LLVM Project Council, this is a proposed list of lead maintainers for the MLIR Project. The full list of maintainers expected for MLIR components and nomination criteria are available at https://discourse.llvm.org/t/mlir-project-maintainers/87189. These will be listed in the repo progressively. Full diff: https://github.com/llvm/llvm-project/pull/146928.diff 1 Files Affected:
diff --git a/mlir/Maintainers.md b/mlir/Maintainers.md
new file mode 100644
index 0000000000000..2ff8c515c3d44
--- /dev/null
+++ b/mlir/Maintainers.md
@@ -0,0 +1,30 @@
+# MLIR Maintainers
+
+This file is a list of the [maintainers](https://llvm.org/docs/DeveloperPolicy.html#maintainers) for MLIR.
+
+The following people are the active maintainers for the project.
+For the sake of simplicity, responsibility areas are subdivided into broad categories, which are further
+subdivided into individual components, such as dialects.
+Please reach out to them for code reviews, questions about their area of expertise, or other assistance.
+
+## Lead Maintainers
+
+Lead Maintainers are responsible for the entirety of the MLIR project, in particular for components not
+covered by anyone else, and can also serve as escalation contacts for arbitration.
+
+- Alex Zinenko \
+ [email protected] (email),
+ [@ftynse](https://github.com/ftynse) (GitHub),
+ ftynse (Discourse)
+- Renato Golin \
+ [email protected] (email),
+ [@rengolin](https://github.com/rengolin) (GitHub),
+ rengolin (Discourse)
+- Jacques Pienaar \
+ [email protected] (email),
+ [@jpienaar](https://github.com/jpienaar) (GitHub),
+ jpienaar (Discourse)
+- Matthias Springer \
+ [email protected] (email),
+ [@matthias-springer](https://github.com/matthias-springer) (GitHub),
+ matthias-springer (Discourse)
|
|
@llvm/project-council since this is a top-level project, I'm looking for approval from the Project Council. @jpienaar , @matthias-springer , @rengolin – please approve to certify that you volunteer to become a maintainer. |
There was a problem hiding this comment.
I'm concerned about introducing a notion of "lead maintainers" for the project right now: the terminology "lead" can be quite misleading.
Also populating the "catch all" maintainer with the "area team" which has a distinct responsibility does not seem straightforward to me.
While there can be overlap between the area team this, just taking over this position entirely like this looks like an over-reach to me.
In what way? FWIW, I strongly support this. MLIR has no maintainers file and this is a problem in practice because those outside of MLIR are uncertain of who to reach out to. This has come up a few times and I appreciate that @ftynse addressing that concern. Regardless of whether "lead" is misleading or not (that's open to debate), that's the terminology used by the community.
I'm confused. Nothing in the PR says "area team" nor in the link to Discourse. Edit: oh, you're talking about the fact that the lead maintainers proposed are the same folks on the area team. I see no issue with that. You can hold multiple roles in the community and still keep them distinct (I'm the lead maintainer for Clang and on the Clang area team; Nikita is the lead maintainer for LLVM and on the LLVM area team, etc). |
|
I took the terminology from the Developer Policy, paragraph 4:
|
Thank you for the ping! I've added this topic to the Project Council agenda for our July meeting. We're in the process of scheduling it, so it may be a few weeks before you hear back from us, just to set expectations on the timeline. |
Defining maintainers is a different problem that defining leads maintainers specifically.
I am questioning this indeed: the responsibility of the area team is to find the most suitable maintainers for each area. Of course area team members are eligible, and it makes sense that there is overlap and we'll find some area team member to also be the obvious maintainers for the project. However that shouldn't be automatic (at least I took it as such when the area team were formed: I didn't even self-nominate to the area team based on this specific understanding of the process!). So I don't agree with the "let's use the area team as lead maintainers just because". I absolutely don't think that this is the best possible nomination for MLIR as a whole here, it is possible that the MLIR area team didn't think it through and use themselves as "default", but in this case which case I would argue to explicitly say: "we don't have lead maintainers in MLIR and the area team is playing catch-all when needed". Otherwise I have strong concerns with the way we end up with the area team alone here: that alone should raise some concerns @AaronBallman in terms of the whole process. |
|
As we were looking for additional maintainers for some of the components, I was running a simple script to count the number of commits in the MLIR directory. (Not an ideal metric, as this is not taking into account code reviews or interactions on Discord/Discourse, but easy data to gather.) We are in the somewhat odd situation that the most active folks are either "unavailable" (no longer active in upstream MLIR development and/or have not responded to the call of maintainers) or us (the current area team members). Please reach out to us if you think we missed an obvious candidate. |
Yes, this is why I nominated individuals in this PR and not "the area team". They just happen to overlap today. The two lists may evolve separately over time and we have policies in place, different for different lists, to ensure that. This is also consistent with paragraph 9 of Area Team description in LP0004.
It is not automatic. If you see anything in this PR or my or the Area Team communication that implies otherwise, please let me know, and I will correct that.
The Area Team made a call for volunteers on Discourse: https://discourse.llvm.org/t/call-for-maintainer-volunteers/86229. We made the choice to keep these initial nominations private to avoid self-censorship for slightly more "junior" community members who are otherwise perfectly qualified to take on the role. We received multiple nominations, the majority of which were self-nominations, but not only. Including your submission for self-nomination. We collected these nominations in a document and made a comprehensive review of the sub-areas in MLIR that were lacking coverage. We then solicited additional nominations from active developers in such sub-areas and also received several spontaneous nominations at a later date. It took us a month and numerous iterations to come up with the list based on the criteria I listed in paragraph 4 of the announcement post. Note that the list and the post itself were approved unanimously by the Area Team, though I will take responsibility for any awkward writing in it as the chair of the team. Obviously, not being a member of the Area Team because you apparently chose not to run for that election, means that you are not privy to the details of the discussion, but I would appreciate if you didn't throw around accusations unless you can substantiate them. We are specifically not saying "we don't have lead maintainers in MLIR and the area team is playing catch-all when needed" as you allege since it would be contrary to the policy as quoted above. We are, however, delivering on the responsibilities of the Area Team as outlined in paragraph 4 of the same section:
and we deemed this choice appropriate. We are obviously aware of the following caveat:
hence the request to the Project Council. If you have a specific nomination to make, please make the case for it and it will be considered by the appropriate body. |
As with other nominations, this shall be done after this process finishes, so that we can have forward progress. This PR is as is and, as Alex points out, has been approved unanimously by the area team after being open for volunteers and having extensive review by a month, strictly following the process encoded in the LLVM project's policies. |
Can you please clarify where did you read any accusations?
I didn't allege anything here: I explicitly emitted this as a hypothetical and asked question. Since your decision process is quite opaque from someone on the other side, and you haven't been willing to elaborate, I'm left to do just this (make hypotheses).
Well I'm pretty sure I self nominated to do "catch all" maintainer: which I actually have been doing this since the project inception basically. So you didn't talk to me, but you made a call, and now you're throwing this sentence here which I can't really makes sense of TBH. |
Certainly. Here:
you rather clearly implying that the Area Team did not justify its decisions (the "just because" part) and generally is not fulfilling its responsibilities ("didn't think it through"). Even if you clarify that you were emitting a hypothesis, this hypothesis is accusatory in nature and is premised on incompetence or otherwise lack of fitness-for-duty of the Area Team.
An allegation is a statement affirming a wrongdoing that is yet to be proved. It appears to me that you are affirming, or at least hypothesizing, that the Area Team somehow did something wrong. Both an allegation and a hypothesis would normally require some proof/evidence. I'm happy to discuss yours.
My apologies, I may be misreading the text, but I don't really see anything that looks like a question or ends with a question mark. If you have a specific question there, please highlight that, I will try to provide the best answer possible.
We did receive your self-nomination volunteering to maintain everything except for tensor compiler (I don't have the exact quote right now, but I am happy to look it up on Monday if needed). We did take it into account and made our own nomination – maintainer of the core category – based on the factors described in the announcement post I already quoted. We never promised that we will automatically satisfy all self-nominations. Let me also say that I highly appreciate your personal contribution to the MLIR project, including code reviews, design insights, overall LLVM experience and running ODMs (now I realize these are harder than they look), to name a few. I remember you joining the project back at Google and helping it become more general and robust – though not without friction – by establishing the earlier project culture, some of which persists today. That being said, I would also like us all to acknowledge that even then it was a collective effort and do not disregard significant contributions of other people, many of whom took part in code and RFC reviews, shifted around "code ownership" of different areas, and helped onboard new community members. Some of these people no longer contribute, and some are still around and are serving on the Area Team. If you have any specific questions, we will try our best to answer them. Once we have an established list of lead maintainers for MLIR, one will be able to make nominations for maintainer roles beyond those the Area Team currently has listed. I'm happy to facilitate the process of these nominations from your behalf as well as from any other contributor. |
This is your inference, absolutely not my intent, please don't assume bad intent. This isn't conductive to a reasonable change. There is no accusation here.
Fact is that I disagree with the conclusion of a process for which I don't have access to the reasoning, and for which despite asking privately I couldn't get clearer information. Now, it turns out I was wrong with this hypothesis, so I'm back to "I still don't agree with the list, and I don't understand your rationale because you haven't provided the reasoning behind it", but I'm lacking hypotheses: what are my next steps according to you?
Well let's just turn one comma into a question mark without changing the sense of the sentence (I made a guess, it was a call for clarifications):
I also asked you questions privately (with actual questions marks!) but that hasn't led any clear answers so far. |
|
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 RepresentationThe 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 Self-nominationsWe 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 RequirementsFollowing 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 Final RemarksThroughout 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 about everything, 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 |
|
It's weird you want to take the approach of being very "process oriented" and focus on the "legalese" instead trying to facilitate a resolution here. I didn't try to discuss legalese so far because it seemed secondary to me: the trust relationship of the community with respect to the area team is what matters more.
Here the area team can nominate maintainer, not decide who is/isn't a maintainer. So you made here a nomination, we have to look into how these are approved then. It is explicitly mentioned also:
Luckily this is covered in the developer policy:
I believe you made a nomination and we're in the case covered here. |
I believe I covered here above:
Yup. Simple as that. As @ftynse said in the beginning:
We're neither judge nor jury. We're more like civil servants. We compiled the list, got nominations (including yours) and acted upon it. We present our findings and we propose it to the council. However, we did ask that the process be done in increments, so we can have forward progress. We don't have a list today, we want to have an interim list with this PR and the follow ups for the remaining maintainers. Once that's in, anyone can volunteer and if there are no objections, the PR is merged. Simple as that. I'm having trouble understanding your reaction, and the aggressive tone you're using in every reply here. You somehow interpreted this as much more than it really is, made some pretty objectionable hypothesis and seems to be acting in self-defense when no one is attacking you. I am not "speaking legalese" (another unnecessary slander), and I am trying to facilitate, despite your accusation of the contrary. I hope your last message means you now understand what's the point of this PR and let us continue with the process. |
I think a reason people keep bringing up the community policies and quoting them is because they're trying to gently remind you that this PR is following the established community policies. It's clear you disagree with the community policies, but this is not the appropriate venue for trying to affect change to them. If you have concerns with the ability of the nominees to perform the duties of maintaining, please say so and explain what those concerns are. If you don't have those concerns, then please do not block the PR on your disagreement with what community policy is or should be. |
I probably didn't make my point clear: there is a situation with a disagreement somehow, and the area team is supposed to be the facilitator for such cases, but since the disagreement stem from an action of the area team, that means you have to facilitate a decision on this action you initiated, this is what I meant by "judge and jury". There is no a criticism in being "judge and jury", it's just that being in this situation I would think that there would be more attempt to find a way to reach a consensual agreement instead of what I perceive to be an attitude of "this is our decision, deal with it" (which is almost word-to-word what I was answered privately before the discussion here!).
So basically I self-nominating myself, I got ignored/rejected by the area team, without being reached to about it, and then when asking privately to some member of the area team questions about it to be able to understand I receive a non-answer along the line of "this is the decision, I stand by it". I also got very conflicting messaging where one member of the area team said "the lead one is just area team copied. As it would be the current escalation path - but should only be an escalation path", which seemed reasonable to me (also the process must be bootstrapped...), but then I got a very different messaging from @ftynse which denied this was the case and insisted these were actually individual nominations. It's been weird that when I repeated the answer I got from one area team member as an hypothesis above it got weirdly reframed as an accusation somehow.
Slander? Really? I wasn't even aware of any negative connotations of the word "legalese": to me it just means to have a strict reading of the letter of law (here that would be the developer policy and other written processes). Sticking to the letter of the policy is one valid approach of facilitating decisions (it does not help understanding decisions when you're on the other side though: so pardon me for expressing my lack of understanding).
@AaronBallman : can you elaborate where did I disagree with the community policy? I don't believe I did, which is why I feel unheard and perceive this policy discussion as just not being willing to answer. I expressed a problem I have the nomination, just as mentioned in the developer policy. I would expect the area team to facilitate a resolution instead of just working around my questions as "not following the policy", and your message here is along the same lines somehow: it's been all about processes! I also expressed my concern with the area team not acting as facilitator here, in the way they answered my questions (first privately), which again is not a objection with the policy itself but with the way I perceived some sort of "steamrolling" happening here. |
I'm not sure why you keep repeating it. Your nomination was acted upon as described by me above (now twice, so I won't repeat).
IIUC, you got partial information from different people while they were deliberating on a very complicated subject and is now confused as to why the messaging wasn't complete and in unison?
There wasn't any. You nominated to "non tensor" and we didn't add you to tensor. I'm not sure I can phrase this in another way that is clearer. However, this PR is not about your nomination, but other people's. If you want to nominate yourself later, as you expressed earlier, you're free to do so in a separate PR.
Do you have concerns on these four people performing the high-level work of conflict resolution and general project management? |
Apologies, I didn't intend to put words in your mouth. That was my perception of your perspective based on comments like:
and
because this PR doesn't introduce the notion of lead maintainers; that's existing community policy.
I think something is unclear to me and maybe others: are you self-nominating to be the lead maintainer for MLIR? My understanding was that your self-nomination was:
and
"Everything but" is not a lead maintainer which may explain the confusion as to why you're blocking progress on these other nominations for that role. From our developer policy:
"span the whole project rather than a limited area within the project" is why I think your self-nomination is for something different than what this PR is about. If you don't have reason to oppose anyone's nomination in this PR, there's no reason to request changes. That gives everyone in the community the impression that you have concerns with their nominations. If you would like to modify your self-nomination, that can certainly be handled in a separate PR/forum discussion without blocking these nominees. |
I'm sorry if that wording is not ideal. I'm trying to follow your style of communication in hopes that it would be more understandable to you, but I may not be getting it entirely right. There is no bad intent in my communication either.
You are correct, we are making a nomination here. There is no process for approving these because top-level projects are now expected to have lead maintainers from the start (not sure what the policy was when MLIR was first merged, but that is not the point here). This is why we immediately raised the issue to the Project Council.
You did not ask about your self-nomination specifically. You did question the process, formulated a hypothesis about the lack of due diligence and stated your disagreement with the conclusion. I tried to address those by providing more details on the process than I did previously and by refuting your hypothesis. And yes, you can absolutely send a PR of your own, nominating yourself or any other eligible contributor. So can anyone. We are not trying to override that. This is exactly what I was saying as both Renato and Aaron seem to have understood from my answer. For transparency, here are my answers from the private conversation you are mentioning:
Just to clarify if this may be confusing, I implied that I would stand by the area team decision to nominate these individuals. I also believe that such matters are better discussed publicly because they concern the entire community. The answer about why you haven't been nominated as lead maintainer (even though there is still no direct question about that!) lies right there: you did not nominate yourself, and we made an effort to accommodate your actual request. The tensor compiler is a significant – and most contentious – part of MLIR, likely requiring most work from the lead maintainers. Historically, you have also interacted less with its main dialects (Linalg, TOSA, memref), so we did not want to force these on you either. It looks like Aaron has the same reading of your nomination as we did. For reference, we did have self-nominations saying just "Everything."
I have a different reading of that conversation, where both me and another member of the Area Team were involved, but I cannot disclose exact wording of a private communication without that person's agreement. In what I see, they were initially confused by your question and thought it referred to the membership in the Area Team itself, not nominations. You can try to clarify it with them.
This is also why we immediately raised the issue to the Project Council. It sounds dubious to serve as a moderator in a discussion where the Area Team is also one of the participants.
We all understand that you are upset and may feel hurt because you were not nominated by us. This does not mean we do not value your contribution to the project, as I already mentioned above. Quite the opposite, we were satisfying what looked like an explicit request from your part. I also don't believe we are avoiding a discussion or trying to shut you down, and we are happy to work towards a consensus and facilitate consensus elsewhere. It is, however, difficult, to do so without further specific questions or concerns. If you keep repeating a variation of the same question, you are likely to get the same answer. |
Thanks for elaborating @AaronBallman, there has been phases in the discussion (including some private ones) which are difficult to disentangle. Some of it has been my ignorance of the process (I didn't disagree with the process, just didn't remember about all the intricacy of it), but that was easily cleared out. So: sorry for the confusion on this PR, and thanks again for attempting to tag along.
One issue here is that there wasn't a call for nomination for lead maintainer, there was form that (from memory) didn't have a box with areas (including "lead maintainer") but was asking something along the line of "which area do you want to maintain", and since the "tensor compiler" area is a recently well identified component that people stood up to maintain, I didn't feel like I was needed there, hence what I wrote! This is also why it feels to me like a "gotcha" and why I can't comprehend @ftynse 's answer here (unless I missed the checkbox in the form? In which case: my bad). Now that it is cleared up, and for the sake of progress, let's get back to getting this done. The role of "MLIR Lead Maintainers" is critical to the health and direction of the project. I believe we're looking for individuals with a substantial and broad track record of involvement across the project (and in particular in the more core components) — spanning architecture, diverse technical areas, and long-term impact. This includes demonstrated expertise through contributions such as code, reviews, and RFCs, as well as a deep understanding of the system’s design principles, trade-offs, and invariants — all of which have helped shape MLIR into what it is today. |
Can you clarify which of the nominees you're concerned about, why, and why would your concerns void their eligibility to be a lead maintainer? |
There was no such checkbox. I understand it may not have been specified clearly enough, but we were trying to keep the list as open as possible. The call was also to help us formulate the initial nominations, this does not preclude people from nominating themselves through PRs, but aggregates the discussion instead of having ~50 distinct and easy-to-miss PRs. I am happy that we seem to have managed to clear out some of the points for you. If you have remaining questions, please don't hesitate to ask.
Why not both? :) We can start the discussion here, and if we can't converge before the Project Council meeting, we will consider our options (or ask them for their preferred way)? |
|
Same as Matthias, approval meaning that I'm willing to take on the maintainer role. |
|
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. 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. 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.” 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. |
|
As discussed during the Project Council meeting, the Project Council will work on clearer role description and criteria for selecting Lead Maintainers with interested parties. I am converting this PR to a draft until that happens. |
Historically, MLIR project has not had a public list of maintainers, unlike the rest of the LLVM project and at odds with the developer policy. The MLIR Area Team initiated a process for (self-)nomination of maintainers in order to remedy this, and is now proposing to establish this list.
Following the self-nominations, discussions in the MLIR Area Team and the LLVM Project Council, this is a proposed list of lead maintainers for the MLIR Project.
The full list of maintainers expected for MLIR components and nomination criteria are available at https://discourse.llvm.org/t/mlir-project-maintainers/87189. These will be listed in the repo progressively.