[META] Identify component maintainers for components with no maintainer listed in MAINTAINERS.txt

There are also a few modules with outdated maintainers. Really, we need to go through all the maintainers in MAINTAINERS.txt and see:
- if they are willing to fulfill the role
- if they are actually fulfilling the role

For instance, I know that search.module has a maintainer listed who has not done anything for that module in a couple of years, and I've been unable to get my supposed co-maintainers for the Transliteration component to review my patches, despite repeated inquiries (and without anyone to review patches I may be unwilling to continue as maintainer of that component either).

I also just marked #2042309: MAINTAINERS.txt does not have entry for several modules as a duplicate of this issue, since this one is more complete, better organized, etc.

xmlrpc.inc is D7, xmlrpc.module is D8

Updated issue summary.

I'm happy to put my hand up to help with comment module if _dixon will have me, a lot of comment will be moved about with #731724: Convert comment settings into a field to make them work with CMI and non-node entities so it makes sense that I stick around to deal with any fall out :)

I could take a history module because following from begining
Also I could recommend @claudiu.cristea for image module

Just one #2054181: Add andypost as a component maintainer for history.module for second issue suppose better to ping claudiu in IRC

Updated issue summary.

Adding toolbar maintainer issue

pwolanin indicated today in IRC that he would be willing to maintain search.module. Unfortunately he also nominated me for co-maintainership... which I might be convinced of but I am unsure after my 7.x experience with same.

Now with the right issue number

Note also #1203886: Remove the PHP module from Drupal core might remove php with any luck

I've been wanting to #445990-24: [META] Refactor color module for a while now. Granted I know it probably won't change in D8 at all since there's really no time. But I'd be willing to take it on so we can move forward in D9.

Updated issue summary.

Updated issue summary.

Removed serialization module since that was committed.

Missing datetime module

Willing to support and fix comment module #2099977: Add andypost as a component maintainer for comment.module
because core accepted #731724: Convert comment settings into a field to make them work with CMI and non-node entities

Updated issue summary.

added myself to Overlay

This process is long and difficult, but let's tackle the easy parts first #2190699: Add missing modules to MAINTAINERS.txt

Added #2300583: Consider adding larowlan and tim-e as contact module maintainers

Added myself to Link module: #2474677: Add Mac_Weber to MAINTAINERS.txt for the link.module

Added DateTime.

Added Database Logging to list of Component listed with no maintainer.

Moved Telephone module to list of Component listed with no maintainer.

Database & drivers (except mysql) also missing maintainers

Added child issues
- #3178983: Clean-up Testing from topic maintainers
- #1921504: Create a Condition system component for core

I think this is outdated, MAINTAINERS.txt refers to subsystems as of late 2016, #2785891: The distinctions between modules, themes, and other subsystems are not relevant in MAINTAINERS.txt or the issue queue component field.

If this is outdated, where do we go to find this information now? Or is the file correct and the issue out of date?

I am not following you. The information in the IS is outdated, it no longer matches the components in MAINTAINERS.txt.
What information do you think needs to be kept?

I just did not understand what "this" was in "this is outdated", sorry. You've answered my question.

It wasn't any fun but I updated the Issue Summary.

@quietone: I am the subsystem maintainer for the Database API. AFAIK that also makes me the maintainer of the MySQL, PostgreSQL and SQLite modules. Only on your updated list the PostgreSQL and SQLite database drivers are marked as "no listed maintainer". Do I need to create an issue to aslo become the maintainer of those modules? BTW, the database drivers now live in modules. Should the maintainers.TXT file be updated for that?

Hello,
It's been three years since the last comment, I was wondering if you can help me to clarify the process for new volunteers to become or be assigned as maintainers for core modules or subsystem components.

According to the latest MAINTAINERS.txt file (from 11.x-dev), the following modules/components are still listed with "- ?":

• Authentication and Authorization
• Automated Cron
• Ban
• Bootstrap
• Content Moderation
• Content Translation
• Cron
• Database Update API
• Filter
• Image
• Inline Form Errors
• Installer
• Language
• Lock
• Mail
• Markup
• Menu UI
• MySQL DB driver
• Options
• Path
• PostgreSQL DB driver
• Request Processing
• Settings Tray
• Sqlite DB driver
• System (module)
• Token
• Documentation
• Workflows

For anyone interested in becoming a maintainer for one of these, what is the proper procedure? Could someone please clarify:

1. Where should one express interest in maintaining a module/component (e.g., by opening an issue or posting here)?
2. Who decides or appoints new maintainers?
3. Is there a priority list indicating which of the above components need help the most?

Cheers

@magunz, see my reply.

As agree in the governance issue, #3458223: Adopt renewable terms for subsystem and topic maintainers, the subsystem and topic maintainers are now contacted annually to find out if they wish to keep the position or step down.

The first check-in was this year, 2025. As it was the first, a new process needed to be created and documented. To do that griffynh, a Leadership Team Facilitator, and myself met regularly, and consulted with the wider Leadership team as needed. This new process is documented at Subsystem or Topic Maintainer Check-in. Like most documentation it is a living document and will change as the process matures.

One outcome from the 2025 check-in is that MAINTAINERS.txt is up to date. (Well, mostly, there are 2 maintainers to follow up on.) There are still open positions, so a new issue has been created to advertise those to the community. It is a child of this issue and will be open until the next check-in. Then, when the next check-in is complete a new issue will be created for the open positions and the previous one closed. That should result in a new issue every year advertising the open positions.

A big thank you to griffynh for all the work to get the check-in process up and running. He created the tracking spreadsheet, the email templates, documentation and actually ran the first check-in. We could not have done this without him.

Adding credit to griffynh.

We've had another round of applications and new maintainers. There will be another check in later in the year where we go through this process again, but for the time being there is nothing to do here.