Drupal Association members fund grants that make connections all over the world.
Last updated August 24, 2015.
Drupal has thousands of contributed projects, each with one "owner" maintainer who has full access to the project and any number of co-maintainers with varying levels of access granted by the project owner.
While most maintainers continue to care for their projects after the initial release, some need to move on and leave the project in the care of the community. Ideally, maintainers will put up a note that the project is in need of a new maintainer so the work can continue uninterrupted. (The process of looking for a new (co)maintainer is described here.) Occasionally, though, maintainers will stop maintaining a project without explanation. While experienced Drupal users know to check the queue and the git commits to determine the health of a project, having broken and unmaintained/unsupported projects available can be confusing and off-putting for new users.
If you find a project that appears to be unsupported or want to recover one, please follow the procedure below:
Becoming owner of a project
If you are a developer and would like to take over ownership of the project:
- File an issue in that project's queue under the "support request" category stating your request to take over ownership or assist in maintainership. If you have a patch for the module, mention that as well, as it shows you are already working on the code. For the title, use something like
Offering to maintain PROJECT_NAME. By putting the project name in the title, you can catch the attention of people reading via the global tracker.
Another way to try to get the attention of the project owner or other maintainers is by using the druplicon bot on irc chat on either the #drupal or #drupal-support channels. If the owner has an IRC nickname listed on their user profile page, the druplicon bot can be tasked with notifying the owner by issuing a command similar to the following:
- Also contact the current project owner via the contact tab on their user profile page to let them know about the issue you just posted and that if you don't hear back in the issue within two weeks the project could be marked unsupported.
- Wait two weeks to give the maintainers time to respond.
- If there is no response or if the owner responds and gives the ok to change owners, move the issue to the Drupal.org project ownership queue, by changing the issue's "Project" field to be "Drupal.org project ownership" and the "Component" field to be "Ownership transfer", to bring it to the attention of someone with access to make the change. Please include a link back to the project page, as well as confirmation that you have completed the previous steps, to make it easier for the Drupal.org webmasters.
Druplicon: tell examplename that I am willing to be a co-maintainer/maintainer of the abc module, view http://drupal.org/node/12345
Note - if you don't already have Git access, you'll need to obtain Git access.
Reporting projects without becoming a maintainer
If you are unable to take over the project yourself:
- 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.
- File an issue in that project's queue under the
support requestcategory politely asking if it is still maintained. For the title, use something like
Is PROJECT_NAME still being maintained?. By putting the project name in the title, you can catch the attention of people reading via the global tracker.
- Also contact the current project owner via the contact tab on their user profile page to let them know about the issue you just posted and that if you don't hear back in the issue within two weeks the project could be unsupported.
- Wait two weeks to give the maintainer time to respond.
- If there is no response, move the issue to the Drupal.org project ownership issue queue, by changing the issue's "Project" field to be "Drupal.org project ownership" and the "Component" field to be "Abandoned/unsupported projects", to bring it to the attention of someone with access to make the change.
- Change the issue title to something like,
PROJECT_NAME appears to be unsupportedand list your reasons for this, as well as noting that the maintainer has not responded. Please include a link back to the project page to make it easier for the Drupal.org webmasters.
- If you feel the project is not only unsupported but badly broken (unusably so), mention your reasons for that as well.
- A webmaster should carefully review the project. If they agree with the assessment, they can then add a note to the project page that the project is in need of a new maintainer and link to a replacement module if one exists. Here is a template that can be used:
Note: As of YYYY-MM-DD, this project appears to no longer be supported. If you are interested in taking this project over, or you as the project maintainer feel this message has been posted in error, please reply to [link to webmasters issue].
- If the webmaster agrees the project is badly broken and not recommended to use, they should unpublish all of the releases as well. If a replacement project is known, link to that project. This should only be done if absolutely necessary as unpublishing the releases will cause update status to notify everyone currently using the project that it is no longer supported. Because of the effects on the users, the webmaster should install the module first to verify that it is unusable before taking this step.
Taking over an obsolete project's namespace
There exist obsolete projects in the Drupal.org git repo that have no users and are no longer useful. For instance, there once was a theme named “console” that nobody maintained any more. That namespace made perfect sense for a new project, so a transfer of the “console” namespace to a new maintainer was arranged.
In such cases, we don't want to lose historic code. Before a transfer of namespace can take place, the person who requests the namespace must transfer the old repo into a sandbox project to preserve its history. To do this, please follow these instructions for Archiving a full project in a sandbox. You should also put up a note on the project page (e.g. in the "Credits" section) and mentioned that the project that previous populated the namespace has been archived in a sandbox, with a link to the sandbox.
Note: If you take over an obsolete project and you don't want to maintain or support the old code (i.e. you want to replace the old code with your own code that more or less fills the same purpose as the old code), you should not archive the old code in a sandbox. Instead you should create a new branch of the project and put up a note on the project page that only the new branch shall be maintained.
Special note on projects marked unsupported for security reasons
If you wish to take over a project that is marked as unsupported for security reasons, post a patch to the project's issue queue which addresses the vulnerability and reference that patch in your request to take over the project. Then send a message to firstname.lastname@example.org asking for a security team member to confirm in your request issue that your patch resolves the security issue. Refer to the security announcement which led to the project becoming unsupported for information about the vulnerability. Contact the security team if you are unsure about the nature or scope of the security issue or need additional information.
We currently don't transfer sandboxes because it causes technical problems and moreover, it is not necessary. If you want to take over an abandoned/unsupported sandbox and maintain it, simply clone it.
If you need the namespace the sandbox is using you need to file an issue though because a webmaster has to alter the name of the blocking sandbox. After this is done you can take the desired namespace for your project.
If you are dealing with an abandoned translation group
See the procedure for translation groups which are managed differently than other projects.
Things you don't 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 don't want to do it. Here are some of those reasons and ways to deal with them:
- I don't like how it's written and don't want to learn the old code. You don't have to maintain or support the old code. You can create a new branch of the project and only maintain the new branch.
- I don't want to support existing users. You don't need to support existing users, though if your project provides a good alternative to their current broken system they may love you. You can state on the project page which branches are supported.
- I don't 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.