How to become project owner, maintainer, or co-maintainer

Last updated on
23 October 2023

This documentation needs work. See "Help improve this page" in the sidebar.

Becoming owner, maintainer, or co-maintainer of a project

Please read in the Terminology page the meaning given to project owner, maintainer, and co-maintainer in this and other pages. In particular, see the difference between maintainer and co-maintainer, which is very important in these requests.

When the project is covered by Drupal's security advisory policy, you need to have permission to opt into security advisory coverage, or the offer must be approved by the project's owner. The site moderators will not add as owner, maintainer, or co-maintainer a user who cannot opt projects into security coverage. See Apply for permission to opt into security advisory coverage for details on how to obtain that permission.

Shared (corporate) accounts are not allowed to commit code to the Drupal.org repository and cannot gain permission to opt into security advisory coverage. However, shared accounts can be project owners, even for a project covered by Drupal's security advisory policy.

If you are a developer who have been working in the issue queues of a Drupal-contributed project, and you find that your work is being ignored by the maintainers/co-maintainers, the patches you've carefully reviewed do not get committed, or there is not any further progress, you may be interested in being added as a co-maintainer/maintainer or becoming the project owner, to advance the development of the project. You could also use this procedure if you are a co-maintainer and you think it is more appropriate for you to become maintainer or project owner.

The following is the procedure to become the owner, maintainer, or co-maintainer of an existing Drupal-contributed project hosted on Drupal.org.

  1. File an issue in the project's queue, using Support request as a category and stating your interest in becoming the owner, maintainer,  or co-maintainer. Giving a link to issues for that project where you posted a patch or where you reviewed patches posted from other users demonstrate you are interested in improving the project, and you are actively involved in the project. Point out the motivation behind your request. (For example, you are already using the project and you want it to be well-maintained.)
    For the title, use Offering to maintain [PROJECT_NAME] or Offering to co-maintain [PROJECT_NAME]. (Replace [PROJECT_NAME] with the project name shown on the project page, not its machine name.) By putting the project name in the title, people reading posts via the global tracker will notice the issue.
  2. If enabled, use the Contact tab on the owner profile page to contact the project owner, asking to post a comment on the issue you posted. We need a comment on the issue you opened to see what the decision of the project owner has been. This step is not mandatory, but it can speed up the process to become owner, maintainer, or co-maintainer.
  3. If you contacted the project owner, or one of the maintainers, report in the issue summary the users who have been contacted for the offer and how.
  4. If the owner replies and sets you up as a co-maintainer or maintainer, the issue is fixed. (There are few users who can change the owner for projects they created.)
  5. If the owner agrees to make you the new owner, but cannot change the project owner, or the owner agrees to your request but does not make any change, move the issue to the Drupal.org project ownership issue queue, by changing the issue's Project field to Drupal.org project ownership. To make it easier for the Drupal.org administrators, please include a link to the project page. If the owner privately agrees to transfer the ownership, ask for a comment on the issue you created.
  6. If the owner does not reply after two weeks, move the issue to the Drupal.org project ownership issue queue, by changing the issue's Project field to Drupal.org project ownership. Please include a link to the project page.
    Site moderators will normally try to contact the owner as an extra safeguard unless it is evident the owner is no longer active in the Drupal community, giving to the contacted users two weeks for replying to the message they sent via the Contact tab.

    If the Contact tab of the project owner is not enabled, wait seven day for a reply. If you do not get any reply from the project owner or one of the maintainers, move the issue in the Drupal.org project ownership issue queue. Some users on drupal.org can contact users even when the Contact tab in their user account page is disabled.

The site moderators will only consider the offer from one person per issue. Please do not use an issue created by another user, even if that issue has not been completed for some reason; instead, open your own issue.

What if you are a co-maintainer who wants to become maintainer or project owner? 

In some cases, project maintainers may have added additional co-maintainers without granting them the Administer maintainers and/or the Administer releases permission. This is an acceptable decision, at the discretion of the project maintainers. 

However, in those cases, if the maintainers are no longer present or have not committed code in the project, and these co-maintainers are willing to take over maintainership, or simply become maintainers, they could create an issue in the project issue queue, following the procedure described in the previous section.
Site moderators will still contact the project owner or maintainers, when there are more than a single maintainer (including the project owner) and at least one of them is still present (which mean those users either posted, commented, or logged-in on drupal.org).

Becoming owner, maintainer, or co-maintainer of a project that is unsupported for security reasons

Please follow the directions on Becoming primary maintainer of a project that is unsupported for security reasons.

Taking over an obsolete project's namespace

There are obsolete projects hosted on Drupal.org that are no longer useful. Users who want to create a new project that uses the same namespace as an obsolete project can take the project over by offering to become the new maintainer. In this case, users should:

  1. File an issue in the project's queue, using Support request as a category and stating your interest in taking over the project namespace. Point out the motivation behind your request.
    For the title, use Taking over the [PROJECT_NAME] namespace. (Replace [PROJECT_NAME] with the project name shown on the project page, not its machine name.) By putting the project name in the title, people reading posts via the global tracker will notice the issue.
  2. If enabled, use the Contact tab on the owner profile page to contact the project owner, asking to post a comment on the issue you posted. We need a comment on the issue you opened to see what the decision of the project owner has been. This step is not mandatory, but it can speed up the process to become owner, maintainer, or co-maintainer.
  3. If you contacted the project owner, report in the issue summary the users who have been contacted for the offer and how.
  4. If the owner replies and sets you up as a project owner, the issue is fixed. (There are few users who can change the owner for projects they created.)
  5. If the owner agrees to make you the new owner but cannot change the project owner, or the owner agrees to your request but does not make any change, move the issue to the Drupal.org project ownership issue queue, by changing the issue's Project field to Drupal.org project ownership. To make it easier for the Drupal.org administrators, please include a link to the project page. If the owner privately agrees to transfer the ownership, ask for a comment on the issue you created.
  6. If the owner does not reply after two weeks, move the issue to the Drupal.org project ownership issue queue, by changing the issue's Project field to Drupal.org project ownership. Please include a link to the project page.
    Site moderators will normally try to contact the owner as an extra safeguard unless it is evident the owner is no longer active in the Drupal community, giving to the contacted users two weeks for replying to the message they sent via the Contact tab.

    If the Contact tab of the project owner is not enabled, wait seven day for a reply. If you do not get any reply from the project owner or one of the maintainers, move the issue in the Drupal.org project ownership issue queue. Some users on drupal.org can contact users even when the Contact tab in their user account page is disabled.

When a project is taken over, we do not want to lose historic code: Existing releases and Git commits will not be deleted. Once transferred, the new maintainers should start a new branch. A note should also be put on the project page (for example in the Credits section) where it is explained that the previous project has been repurposed. Existing releases can be marked as unsupported.

Taking over an empty project, with or without an active maintainer

In the case that a project has not had any code committed after at least 3 months since the project creation, that namespace becomes eligible for a transfer of ownership following the procedure above. 

If the maintainer of an empty project is still active on Drupal.org, there are some additional considerations. 

  • If at all possible, the existing maintainer should be engaged with to voluntarily grant maintainership. 
  • If the existing maintainer is working towards public release of module in good faith, they should be granted an extension to the 3 month window. 
  • Some examples of 'good faith' efforts include: 
    • The existing maintainer is actively developing the module in private, but still targeting a public release. 
    • The existing maintainer is waiting for permission from a client to contribute a module back to the community. 
    • The existing maintainer is actively recruiting contributors.
    • The existing maintainer is actively updating a development roadmap. 
  • Reasons that are not sufficient to hold a namespace
    • Holding a namespace just for the sake of holding it. This is already against Drupal.org policy, whether or not the maintainer is active. 
    • Holding a namespace because there is a privately used module with the same name. For example, if a client site uses a custom module called 'best_module' this does not entitle the maintainer to reserve the namespace 'best_module' on Drupal.org, without the good faith intent to share the code with the community. 

If after evaluating these circumstances, the site moderator believes that ownership of the namespace should be transferred, than it can be moved. The original maintainer may remain on the project if they are willing to collaborate in good faith with the new maintainer. 

Taking over abandoned translation groups

The procedure for abandoned translation groups is described in Taking over abandoned translation groups.

Transferring a project that used a trademark in its short name

The Drupal Association strongly recommends against using a trademark in a project name or short name. In the event that an existing project is using a trademark in the short name there are a few paths forward:

  • Preferred: The existing maintainer and the trademark owner work together. Perhaps creating a new branch for the trademark owner's work. 
  • If the existing maintainer does not want to give maintainership to the trademark holder there are two options: 
    • The existing maintainer can create a new project with a namespace that does not include the trademark and move over their code, and the trademark owner will begin work on a new branch. This prevents disruption for existing users under the namespace.
    • Strongly not preferred: If the existing maintainer does not want the prior maintainer to have access to the repository, an exception can be made for DA Staff to change the project short-name - this *will* be disruptive to current users. The trademark holder can then create a new project with their trademark. 

While it is never the Drupal Association's first choice to remove a namespace from the original maintainer's control, the Drupal Association must comply with domestic and international law on trademark use.

Reporting projects without becoming a maintainer

If you are unable to become the owner of the Drupal-contributed project yourself, but you want to still report projects that seem abandoned/unsupported, you need to:

  1. Review the issue queue and commit messages carefully to be reasonably sure the project is unsupported to avoid annoying a maintainer who may simply be busy.
  2. File an issue in that project's queue under the support request category politely asking if it is still maintained. For the title, use something similar Is [PROJECT_NAME] still being maintained? By putting the project name in the issue title, people reading posts via the global tracker will notice it.
  3. Contact the current project owner via the contact tab (if enabled) on their user profile page to let the project owner know about the issue you just posted and that, without replies in the opened issue and within two weeks, the project could be marked as unsupported.
  4. Wait two weeks to give the project owner the time to reply.
  5. If there is no response, move the issue to the Drupal.org project ownership issue queue, by changing the issue's Project field to Drupal.org project ownership and the Component field to Abandoned/unsupported projects, to bring it to the attention of someone who is able to make any change.
  6. Change the issue title to [PROJECT_NAME] appears to be unsupported. (Replace [PROJECT_NAME] with the project name shown on its project page.) Describe your reasons for this, as well as note that the maintainer has not responded. Please include a link back to the project page to allow site moderators to quickly find the project, avoiding any confusion with projects with similar names. Optionally, you can suggest one or more replacement projects, which the site moderators can decide to link to from the top of the project page.

Things you do not have to worry about

As someone considering taking over a module (or having that suggested to you), you may think that there are some reasons why you do not want to do it. This is a list of some of those reasons and how to deal with them.

  • I do not like how it is written and I do not want to learn the old code.
    You do not have to maintain or support the old code. You can create a new branch of the project and only maintain the new branch.
  • I do not want to support existing users.
    You do not need to support existing users, although they may like your project provides a good alternative to their current broken system. You can state on the project page which branches are supported.
  • I do not want to be associated with a failed project.
    This is just a marketing problem and an easy-to-overcome problem at that. You can alter the project page to point out the benefits of your new version compared to the old one. Now people will become interested in your idea as a replacement for the old one.

Help improve this page

Page status: Needs work

You can: