The area team has carefully and extensively considered all (self-)nominations for maintainership, including late ones, and came up with the structure presented below. Given the complexity and breadth of the MLIR project, we propose a layered system with broad “categories” that are further subdivided per dialect or other component, rather than simple per-directory structure. This is purely an information management decision that is not intended to have any effect on the project layout. The maintainers of categories are conferred with a maintenance burden of the entire category, including directories/dialects/components specifically covered by dedicated maintainers, similarly to how lead maintainers MLIR have the burden of maintaining the entire project in collaboration with other maintainers. Please read more about maintainer status in the LLVM Developer Policy. In particular, significant design changes require a forum RFC and a community-wide discussion, where the role of the maintainer is that of a mediator and a moderator, rather than that of a dictator.
Several dialects/components were considered “important enough” to be maintained directly by the category maintainers. These will have the name of the category listed instead of individual maintainer names. This name is italicized below for readability.
Several other dialects/components do not have maintainers. We call them out below and will consider removing them if nobody volunteers to maintain them. Until that moment, they are maintained by the relevant project and category maintainers.
We based our decisions on multiple criteria to ensure representation, fairness and compliance with the LLVM Developer Policy. In particular, we did not nominate as maintainers individuals who do not have a recent track record of high-quality non-trivial contributions including PRs, reviews, bug reports, and public discussions. This is required by the Developer Policy. We also attempted, to the extent possible, to nominate multiple maintainers for every entry (being able to go on vacation is nice!). Finally, we tried to balance representation from different organizations whenever applicable, i.e., except vendor-specific components.
This list of maintainers is iterative and this is our first attempt at establishing one after more than 5 years of MLIR in the monorepo. It may and will evolve according to the policy in effect, and individual contributors are welcome to nominate themselves or somebody else according to the policy.
The list below uses Github handles (or my mistaken spelling of those).
Next steps:
We will send a first PR committing the list of lead maintainers for approval by the Project Council members.
After that, we will send PRs per category. These must be approved by the nominees to record their agreement to take up the responsibility.
After that, category maintainers are invited to follow the same process for individual entries within their category.
Steps 2 and 3 are a direct transposition of the Developer Policy.
Lead MLIR Project Maintainers (escalation / everything not covered below)
I was on a leave during the call for nominations and missed that thread or wherever that happened.
Several other dialects/components do not have maintainers. We call them out below and will consider removing them if nobody volunteers to maintain them.
If it’s not too late, you can also consider me for arith and ub. The latter is currently listed a unmaintained. @Hardcode84 is probably also interested.
Thanks for volunteering! It may be too late for this particular process, but this is just the first slate to start. You are most welcome to just follow the regular procedure by sending a PR for approval to category maintainers once those are in place, I’ll let you know!
Thanks for all the effort the area team is putting into this!
Having maintainers for the ub dialect would be important, indeed. The ub.poison op has already been adopted in a few places of the ecosystem. Having dedicated maintainers that can help fill some of the existing implementation gaps (e.g., representational support for partially poison vector types) would be highly appreciated.
This is probably a little off-topic, but I found this taxonomy of the different dialects really helpful for demystifying what the different dialects in MLIR are and where one might want to focus their learning efforts if they were new. At the very least, it’s way more useful than what we currently have.
Should it be encoded in the documentation somewhere, somehow?
We intentionally don’t propose a way to structure the project with this change, that should be a separate discussion, but this list may be a good starting point for that convresation.
Definitely something we need to discuss soon (not here). The taxonomy came from the survey and encodes the “current usage” more than the “expected classification”. But since most dialects are used by more than they were designed for, an expected classification would also be somewhat “wrong”.
Since maintainers need to worry about code and usability, it’s more actionable to bundle by usage at least in a first attempt. But as was said above and elsewhere, this is the first list, not the final one (if there will ever be a final one).
We should continue to evolve and yes, document them more prominently, so that it’s easier and faster to learn about MLIR, which will hopefully increase contributors.
These nominations were discussed at the LLVM Project Council meeting on July 17. As the Project Council and the Area Team currently lack clarity on the exact scope of responsibilities for lead maintainers, we will be holding off those nominations until the Project Council clarifies those so nominations can be evaluated with more objective criteria.
In the meantime, as agreed during the same meeting, we are proceeding with nominations of category maintainers. As an exception, in absence of lead or any other maintainers for the project, the Area Team may approve the nominations as discussed during the same Project Council meeting.
Action Items:
nominees: please confirm the nomination by approving the PR; your approval means accepting the burden of maintainership and nothing more;
everyone: if you have any specific concerns regarding a nominee, please raise them on the PR in such a way that the nomination can be defended; in exceptional cases, you may contact the Area Team via Discourse; if you have concerns that fall under Code of Conduct, please reach out to the Code of Conduct committee.
We will keep these PRs open for a couple of days, but given that there was no specific opposition to these nominations for the two weeks since the initial post, we expect to be able to merge the PRs some time next week. Note that these are PRs just like others and they can be reverted should a major concern arise after merging.
Alex on behalf of the Area Team and Project Council
The category maintainers lists are being merged now. I would kindly ask category maintainers to populate the list further from the post above following the same process. Nominees listed above may also open PRs and ask category maintainers and other nominees to approve them.
I think, at this point, folks willing to volunteer for currently-unmaintained parts are welcome to send PRs nominating themselves for review by relevant category maintainers. Once we are done with the initial list from above, additional maintainers can be nominated everywhere if desired.
Regarding the differences between dialect maintainers, here’s my view of the rationale behind:
The ones marked with team are the core dialects and are a share responsibility of the whole team. These should never be moved out of MLIR, unless the whole community agrees to do so, with strong consensus.
The ones with team and additional maintainers are still the responsibility of the team, but those people are most active in their design. Questions should be directed to these people before the core team. If they cease their activities, ownership goes back to the team.
The ones with just named maintainers are alternative / side dialects that have an active community behind. If they cease their activities, the dialect becomes unmaintained.
The ones marked unmaintained are those that the underlying community has ceased (or drastically reduced) support and will need new maintainers or be considered for removal.
Note that the maintainer list does not cover everyone that works on the dialect, just those that are responsible for its maintenance. This is more of a janitor’s job than a head teacher, as there’s no additional power bestowed (as per the LLVM policy).
I’d mention that not everyone monitors Discourse as actively. Some more follow Github/code . So I suspect this changes as visibility increases (this is also the first roll out of this, so some may want to see it play out first). But then yes, responsibility for maintaining goes upwards through “gaps”. E.g., if dialect has no direct maintainer, then “group” its under is maintainer, if under no group or group not responsive, go up
