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

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

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 no progress, you may be interested in becoming a co-maintainer/maintainer or the project owner in order to further 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.

Offering to be a maintainer/co-maintainer

1. File an issue in the project's queue. Use Support request as the category and state your interest in becoming maintainer or co-maintainer. Adding links to issues for the relevant project in which you have added merge requests or patches or where you have reviewed merge requests or patches from other users will help demonstrate that you are actively involved in the project. Describe 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 the issue name via the global tracker can notice the issue.
2. If enabled, use the Contact tab on the maintainers' profile page to contact them. Request that a comment is posted on the issue you have created. We need a comment on the issue you opened to see what the decision has been. This step is not mandatory, but it can speed up the process to become maintainer or co-maintainer.
3. If you contacted the maintainers, report in the issue summary which maintainers have been contacted regarding the offer and how you contacted them.
4. If maintainers reply and set you up as maintainer or co-maintainer, the issue is fixed.
5. If the maintainers agree to make you maintainer/co-maintainer, but do not make any change, move the issue to the Drupal.org project ownership issue queue. You can move the issue by changing the issue's Project field to Drupal.org project ownership. Please include a link to the project page. If maintainers privately agree to make you maintainer/co-maintainer, ask them to post a comment on the issue you created.
6. If maintainers do not reply in two weeks since the offer appeared in the project issue queue, move the issue to the Drupal.org project ownership issue queue. Move the issue by changing the issue's Project field to Drupal.org project ownership. Please include a link to the project page.
   Project moderators will normally try to contact maintainers as an extra safeguard unless it is evident that they are no longer active in the Drupal community, giving to the contacted maintainers two weeks to reply to the message that they have sent via the Contact tab.
7. Please leave a comment,14 days after the issues was moved, if none of the maintainers rejected the offer. The comment will show you are still interested in the offer and it will allow project moderators to notice they need to take action on the issue.  

Offering to be the new project owner

1. File an issue in the project's queue. Use Support request as the category and state your interest in becoming the project owner. Adding links to issues for the relevant project in which you have added merge requests or patches or where you have reviewed merge requests or patches from other users will help demonstrate that you are actively involved in the project. Describe 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]. (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 the issue name via the global tracker can notice the issue.
2. If enabled, use the Contact tab on the project owner's profile page. Request that a comment is posted on the issue you have created. We need a comment on the issue you opened to see what the decision has been. This step is not mandatory, but it can speed up the process to become the new project owner.
3. If you contacted the project owner, report that in the issue summary and how you contacted the project owner.
4. If the project owner agrees to make you the new owner, move the issue to the Drupal.org project ownership issue queue. You can move the issue 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 ownership, ask that the owner post a comment on the issue that you created.
5. If the project owner does not reply in two weeks since the offer appeared in the project issue queue, move the issue to the Drupal.org project ownership issue queue. Move the issue by changing the issue's Project field to Drupal.org project ownership. Please include a link to the project page.
   Project moderators will normally try to contact maintainers as an extra safeguard unless it is evident that they are no longer active in the Drupal community, giving to the contacted maintainers two weeks to reply to the message that they have sent via the Contact tab.
6. Please leave a comment, after 14 days, if the project owner did not reject the offer. The comment will show you are still interested in the offer, and it will allow project moderators to notice they need to take action on the 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 Offering to be maintainer/co-maintainer.
Site moderators will still contact the maintainers (including the project owner), when there are more maintainers and at least one of them is still active on drupal.org (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 project owner profile page to ask to take over the project and suggest 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 you did that and how (for example, via email or via Slack).
4. If the owner replies and sets you up as a project owner, the issue is fixed.
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 in two weeks since the offer appeared in the project issue queue, 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 two weeks to reply to the message they sent via the Contact tab.
7. Please leave a comment, 14 days after the issues was moved, if the project owner did not reject the offer. The comment will show you are still interested in the offer, and it will allow project moderators to notice they need to take action on the issue.

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 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 maintainers of an empty project is still active on Drupal.org, there are some additional considerations.

• If at all possible, the existing maintainers should be engaged with to voluntarily grant maintainership.
• If the existing maintainers are working towards a public release in good faith, they should be granted an extension to the 3 month window.
• Some examples of good faith efforts include:
  • The existing maintainers are actively developing the module in private, but still targeting a public release.
  • The existing maintainers are waiting for permission from a client to contribute a module back to the community.
  • The existing maintainers are actively recruiting contributors.
  • The existing maintainers are 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, project moderators believe that ownership of the namespace should be transferred, then it can be transferred. The original maintainers 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:

• Preferably, the existing maintainers and the trademark owner work together, perhaps creating a new branch for the trademark owner's work.
• In the case the existing maintainers do not want to give maintainership to the trademark holder there are two options.
  • The existing maintainers can create a new project with a namespace that does not include the trademark and move over their code; the trademark owner will start working on a new branch. This prevents disruption for existing users under the namespace.
  • (Strongly not preferred) If the existing maintainers do not want the trademark owner to have access to the repository, an exception can be made for the Drupal Association 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.

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.