The Drupal core committers and Drupal 10 readiness initiative are seeking feedback on a proposed new working group. The group's mission is to focus on contributed modules where a maintainer has not updated to the next major Drupal version. This includes modules where the maintainer has requested assistance as well as modules where the maintainer is no longer active. This effort will benefit the entire Drupal ecosystem.
This group will have elevated privileges on Drupal.org like those that exist for the Security Team and Site Moderators.
Background
Currently the Project Update Bot generates automated compatibility patches for contributed projects. These patches are reviewed and tested by Drupal community members and then set to the "Reviewed & tested by the community" status.
However, for some modules, these patches are not committed in a timely fashion. This creates a barrier to updating to the next Drupal major version for sites that use this module.
There are existing workarounds. One is the Composer Lenient plugin which allows affected sites to install a patched version of the module. However, this is not a substitute for having a compatible version of the module.
Proposal
Establish a working group that has the ability to appoint its members as a temporary maintainer of a project. The only task of the temporary maintainer is to review, test and commit a patch or merge request that makes the module compatible with the new Drupal major version and optionally create a new release. The group will be able to take this action in the following circumstances:
-
The project MUST have a canonical issue for updating to the next major version of Drupal. This issue MUST have a patch or merge request. The issue MUST be marked "Reviewed & tested by the community" and MUST NOT have had feedback from a module maintainer within the past two weeks. The following proposal refers to this as the contributed project issue.
-
An attempt MUST have been made by members of the community to contact the module maintainers via their Drupal.org contact form. Record of this attempt MUST be recorded on the contributed project issue.
-
An attempt SHOULD be made by members of the community to contact the module maintainers via a messaging platform such as the Drupal community Slack. Record of this attempt MUST be recorded on the contributed project issue.
-
If there is no response from the module maintainer for seven (7) days, a member of the community MAY escalate the module to the Project Update Working Group. To escalate a module, create a separate issue in the Project Update Working Group issue queue. This is termed the project update group issue. An attempt SHOULD be made to notify members of the Project Update working group via a messaging platform such as the Drupal community Slack.
-
The Project Update Working Group MUST make a subsequent attempt to contact the module maintainers via their Drupal.org contact form. This communication MUST outline that failure to respond within seven (7) days may result in the Project update Working Group committing the contributed project issue on their behalf. Record of this contact MUST be recorded on the contributed project issue. Any communication between the Project Update Working Group and the module maintainers MUST be recorded on the project update group issue.
-
When the seven-day period from item 5 has elapsed, the maintainer has had two weeks overall to respond. At this point, a member of the Project Update Working Group MUST decide on the next step. The next step is to either intervene or not. If the decision is to intervene, then the group must also decide if a tagged release is to be made as well as committing the change. When making the decision the Project Update Working Group member MUST do the following.
-
Take into consideration recent activity from the maintainer in the project.
-
Take into consideration the age of the contributed project issue.
-
Take into account the complexity of the patch/merge request. They must work to avoid regressions. The level of automated test coverage for the project SHOULD be used to inform the likelihood of a regression.
-
Take into account the quality of the reviews.
-
Take into account the possible lifespan of the module and the needs of the community. For example, if the module duplicates functionality added to core or another module, then they may decide not to intervene.
-
Consider if the module is looking for new maintainers and if anyone has nominated themself for the role. The Project Update Working Group SHOULD favor supporting a new maintainer over intervention.
-
The Project Update Working Group SHOULD aim to achieve compatibility with the major version in a backwards-compatible way.
-
-
If a member of the Project Update Working Group decides to intervene and commit the patch, then the following occurs:
-
A record of the decision MUST be recorded on the contributed project issue.
-
The member of the Project Update Working Group MUST nominate to make the commit and/or release. Record of this nomination MUST occur on the contributed project issue.
-
The member of the Project Update Working Group MUST make a temporary change to the project's maintainers to add themself as a maintainer. Record of this change MUST be made on the contributed project issue.
-
The member of the Project Update Working Group with temporary maintainer access will then commit the patch or merge request. This MUST be recorded on the contributed project issue.
-
The member of the Project Update Working Group MUST acknowledge that the commit was made on the contributed project issue.
-
If it was decided that a release should be made, a member of the Project Update working group will create a tag and add a release node for the tag on Drupal.org. The member making this action MUST make a record of this on the contributed project issue. The release MUST follow semantic versioning rules for backwards compatibility. The member SHOULD strive to make a new minor version to allow sites to install a compatible version without updating the major version of Drupal.
-
If the module maintainer has not requested assistance from The Project Update group, a member of the Project Update Working Group MUST update the project node on Drupal.org to change it to 'No further development'. If the module has opted in to Security team coverage, the member of the Project Update group MAY opt the module out of this coverage.
-
Any member of the Project Update Working Group MUST then mark the original contributed project issue as fixed. This action SHOULD NOT prevent opening of new issues for the project for major version compatibility.
-
A member of the Project Update Working Group MUST revoke the temporary maintainer rights within fourteen (14 days). Record of this change MUST be recorded on the contributed project issue.
-
If the module was marked 'No further development' and if no such issue exists for the contributed project - a member of the Project Update Working Group MUST open a new issue in the project's queue seeking a new maintainer.
-
If additional compatibility issues are found between the module and the next major version of Drupal, the process above repeats.
-
Working group membership
The working group will comprise community members who self-nominate. Interested community members must receive two seconding recommendations from other community members. Nomination and seconding will occur publicly on Drupal.org in the Project Update Working Group issue queue. Community members will be able to share their thoughts or concerns on the nominees' applications. Concerns relating to conduct of members of the group MUST follow Drupal's standard Community Working Group processes.
The initial membership of the group will comprise at least five (5) individuals. Members of the group should have a record of maintaining core or contributed projects and have the git-vetted role on Drupal.org. In addition the group may contain provisional members. These members will not have the ability to change project maintainers and will require the support of a full member to carry out their duties.
The initial make up of the group will be vetted by the core committer team and security team. Subsequent appointments will be vetted by the Project Update Working Group with a fourteen day period for veto from the security team and/or core committers.
Membership of the group is for a single major update. For example, from Drupal 10 to Drupal 11. The first major update in which the group is active will be from Drupal 10 to 11. At the end of each major cycle, members can opt to renew their membership for the next major update cycle. As with the original nomination, this process will happen in public and require two seconding recommendations from the community.
Additional lifecycle option
To complement this process, it is proposed that a new Abandoned lifecycle status is added for project info files.
If this is successful, the following changes will be made;
-
The process at (6) above will be amended such that the module's info file is updated to set the lifecycle value to 'abandoned'.
-
A lifecycle link is added that points to the issue in the project's queue where a new maintainer is sought.
Comment period
Community feedback is sought on the proposed process. Please use this issue to add your input. The feedback period will last until Friday January 12th 2024.