Moderating projects and code

Last updated on

13 July 2022

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

Editing projects

If you find a problem with a module, theme or distribution page, don't edit the project yourself. Instead, create an issue in that project's issue queue to discuss the changes with the project's maintainers. If you believe the problem is in violation of a Drupal.org policy and the maintainer doesn't make the changes, then escalate the issue to the Site Moderators issue queue so others can discuss and help resolve the issue.

Namespace squatting

Projects on Drupal.org should have code pushed to their Git repository or otherwise be used. Community projects are an exception, they are often used for organizing issues without code. Do not create a trivial project just to reserve a namespace.

If you encounter a project that does not meet this requirement some time after creation, please ask the maintainer to change this by creating an issue in the project’s issue queue. If no action is taken by them within a reasonable timeframe, move the issue to the Site Moderators queue.

Removing projects/releases

Users with advanced roles (such as site moderators) should not remove a project or release without talking to the security team first

Deleting or unpublishing projects and releases will cause problems for people using them. We should not pull code out from under people except in extraordinary circumstances, such as valid legal requests. It is best to update pages to explain where to go next for users.

In the exceptional case that a project needs to be removed, unpublishing will prevent a new project being created with the same name, which could deceive users and have them install different code than they intended.

The cases in which a project will be considered for removal:

Proprietary or copyrighted material was published without permission of the owner
Presence of code or assets with an incompatible license
(in very rare cases) An accidentally published project with no releases(including dev releases) and no usage

In all other cases, the project should remain published so that any existing sites depending on it still have access to the code, and so that they can see the unsupported status of the project on the project page and in update status.