[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. |
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.