Lower the bar for module adoption for Drupal 10

Corrected typo in issue summary.

In my opinion, this helped, and significantly increased the number of modules that became Drupal 9 compatible in a timely fashion.

First off let me say I respect the attempt that was done for D8->D9, that it was good intention and that we really couldn't know just how it would necessarily go until we had done it. I even picked up one module through the expedited process (though I'll admit part of the timing was because I was concerned seeing a large number of modules being adopted by users in bulk and I was concerned they may pick up a module they do not have a solid interest in)

I don't have any solid numbers, however by my personal observation I noticed a large number didn't get adopted until well after D8 EOL, and of those that were it appeared a decent number of them were possibly duplicates of other modules or duplicated functionality that could be done in core. I believe I recall at least one case where the module itself had said "don't use me, use this other module its better" and yet we allowed adoption.

I'm concerned we are ending up with modules being adopted that are not being maintained long term and in some cases have acceptable alternatives. I'm never going to tell a developer they cant work on a module, but I'm not one to encourage them to work on something that has valid alternatives either.

On the converse side of that, I saw module adoption attempts by users that appeared to have a solid vested interest in the module, yet because they were not 'security vetted' they couldn't adopt the modules, and we provided no reasonable way for them to prove their ability.

I can understand and agree with the policy that security covered modules need to be adopted by vetted users, but each one of those was a module that might have actually received serious maintainers that we rejected. I stopped following many of them a while ago however I recall one, #3237190: doabarrelroll project open to new maintainer applications on 5 Oct, 2021 → , where now even a year later it doesn't have a maintainer because we turned down the only interested individual. This may not be a bad thing, the module will disappear if no one is seriously interested in it which can help clean up the searches, but its at least worth acknowledging this happened a decent number of times, and that is only the ones we know of where a user didn't realize they couldn't apply.

#3237190: doabarrelroll project open to new maintainer applications on 5 Oct, 2021 → is also an interesting example of the types of modules that were being adopted (even though it never was), it was very very low usage counts, limited functionality, and these are the sorts of projects we were encouraging people to adopt. I question how big a favor we actually did for the community getting these modules up on D9. I suppose if my site absolutely had to have that feature to keep its user base interested as an Easter egg I would be looking at it more thankful that someone adopted it.

The community effort has already adopted a decent number of modules for upgrading to D10. Though I do question how useful these adoptions are since they are taking minimal permissions in the majority of cases (can't even add other users to replace themselves) and in many cases have admitted they may not maintain them long term, I wouldn't be surprised to see many of those modules being re-adopted when D11 comes around.

We should also probably be discussing #3367744-7: Offering to maintain Media Library Extend → here as well since that appears directly related to the process being 'too easy'.
I recall watching the user in question adopt a large number of modules quickly. I recalled wondering as each one got approved "is the Project Ownership team going to ask any questions?" to which they never did. There wasn't anything at the time to trigger any grounds for the ownership team to not approve the requests so no fault to them, but as a security focused mind I remembered thinking "this could go badly", thankfully the worst that appears to have happened was modules being abandoned but it could have been worse.

I recalled wondering as each one got approved "is the Project Ownership team going to ask any questions?" to which they never did.

As you probably know, I am part of the Project Ownership team, and your observation is correct: We never asked any questions. My take on the accelerated process is that our task is to expedite addition of a new team members ASAP. I.e. it is not our place to scrutinize the person's motives, or to curate the Drupal.org ecosystem to kill off "bad" or "superfluous" projects. Doing such things, IMHO, would be overstepping our mandate. We also does not have access to the information necessary to perform this kind of diligence. It was not an ideal system, but it was worth a try. Feel free to suggest how it can be improved.

I agree that recent developments, which you link to, strengthen your argument about the accelerated process tested was "too easy", and that at least some of the new maintainers added lacked long term commitment to the project and an understanding of the responsibilities that comes with being trusted with being made a maintainer.

However, as the EOL of Drupal 9 approaches, I still hope for some discussion about how to ease the transition.

I wild idea: There are a lot of Rector patches sitting in the issue queues with status "RTBC", but nobody around to commit and create a release. Could we script the task of committing these and creating at least a dev-release?

My take on the accelerated process is that our task is to expedite addition of a new team members ASAP

FWIW, I would agree that was what the mandate was. Equally I have a very hard time in being able to quantify this into any actionable set of 'rules' that could be fairly applied other than to say "at the queue admins discretion" and even that may not have changed things. At least going through the formal process requires some effort to show more than just a passing interest, though the negative is this likely is increasing the workload burden for the project ownership team.

Taking over project ownership is essentially a supply chain attack, its sanctioned, but were forcibly injecting our own choice of developers into a project, that isn't a subject that should be taken lightly and in my opinion shouldn't be done in a way that helps enable those with just a passing interest in the modules which is why I'm somewhat against lowering the bar again.

A crazy idea...Could we script the task of committing these and creating at least a dev-release?

Not that crazy actually, #3168047: Commit Project Update Bot patches to under-maintained projects for Drupal 9 compatibility → exists on that subject. I know I read it in the past however I can't recall it enough to summarize where it left off, that is the issue that triggered the D9 adoption process. I have some thoughts, on that, however they are probably of scope for this issue.

Note: Pinging this into #d10readiness since they may have their own opinions on this subject.

A crazy idea: There are a lot of Rector patches for Drupal 10 compatibility sitting in the issue queues with status "RTBC", but nobody around to commit and create a release. Could we script the task of committing these and creating at least a dev-release?

I've toyed with this idea earlier in the whole d10 readiness process while working on Project Update Bot. But in the end it seems this has some serious issues. For one; a lot of modules do not have tests, which is fine, but will mean breakage happen. Second, the review process of a lot of these RTBC issues might not have been very thorough, to asses that you still need a human eye to look and judge.

The result of an action like that would probably result in a large number of instable modules in the ecosystem, with noone around to fix that. I don't feel that is a way forward if we want to keep an healthy ecosystem.

There is an alternative to at least use the modules without to much effort. Assuming you use composer (which you should be using anyways by now ;)). So its not a complete dead end.

See this doc page → but mostly the linked github repository mglaman/composer-drupal-lenient which allows to install incompatible modules and then patch them with the d10 patch.

Counter idea

We come up with an official group for module readiness. With a defined remit outlined in governance policy somewhere.

This group has the ability to commit automated patches and make dev releases on any project where [conditions to be determined that unblock a module upgrade]

We have some prior art here eg The security team can edit any project page within their purview.

The group has an official process for membership and voting on whether to intervene. E.g let's say they need 3 +1 votes from members of said group to intervene. All of this is communicated on the relevant issue for each module.

The process would be that group temporarily edit maintainer list to add one of themselves, make the commit and release, then remove, again documented on the relevant issue

Yes, I am aware of the Lenient Composer Endpoint. I recently even recommended it to a new community member trying to be able use an undermaintained module where the most recent version is AFAIK Drupal 10 compatible except for not having the right core_version_requirement. Please see the full exchange here: https://www.drupal.org/forum/support/post-installation/2023-06-27/ical-i... →

TL;DR: Using "lenient" resulted in an outdated version was downloaded by composer, so it it doesn't automatically solve the problem of installing undermaintained modules on Drupal10, at least not for our inexperienced users.

larowlan,
excellent suggestion! +1 from me.

A pro tempore maintainer for the purpose creating a dev-release of an undermaintained project would be able to solve the most pressing problems of undermaintained projects. With some triage in place, the group could even decide that some superfluous should stay abandoned, and their users nudged towards a better maintained alternative.

If such a group were set up, I would volunteer to help out.

I've been following the "official" process to get added as a co-maintainer pretty successfully now for 3-4 months now. It takes about 4-5 weeks, but at the end of the calendar days, I have commit access and can release a tagged D10 release for just about any module. I am very up front in my request to be added as a co-maintainer that I'm mostly here to get a D10 release out the door. Only 1 of the modules has turned me down out of probably 30 modules. As a side-note, that one rejection had other political issues and the request to get added as a maintainer caused the actual maintainers to release a D10 release. But now sadly I'm listed as a maintainer on something I probably won't touch much until D11 is about to release. If instead of waiting the 4-5 weeks, I could just add a simple Functional test that installs the module and makes sure I can render the settings page (if there isn't any tests yet) and commit a D10 release... I would be super happy. It cuts the timeframe down a _lot_ on these modules.

The downside is that this select club has a lot of power. And an edge up on other vendors who do not have a representative on the team. That team can prioritize any or all modules that their agency uses. But what happens if a little used module surfaces and a small one man shop needs a D10 release for it? How is that handled?

I was actually talking to some people about what you suggest @larowlan when in Pittsburg. I think it could work but there are indeed a few things we need to consider.

1. Maintainer activity on the module: Having a module pushed through when the maintainer has been active on the module in the last few months probably not a good idea.
2. Age of the issue: Although related, the issue should have been open for a while, to give the maintainer the room to at least respond if possible.
3. Complexity of the patch: If the patch is minor this would be fine, but complex patches, that would be risky. If a patch is merged, and the group then leaves, who will support possible regressions? I do feel we need to minimize the risk of putting broken modules out there. The fact is, things might break in unexpected ways.
4. Quality of the reviews: The review of the issue or the changes must be thorough. Comes back to the point before this one, that the quality of the ecosystem is important.
5. Is the module worth it: This is a hard one. How bad is it to have module die at some point? There does need to be a certain amount of "need" to upgrade the module by the community I think. A module with a few installs it probably not worth keeping. Or perhaps, if the upgrade issue had little to no activity (what is little?) it should not be upgraded.

So there should be some checks. But by making sure the group is a set of somewhat experienced (module) developers one could also minimize the checks needed. The risk of writing down to many specific rules will come bite you in the behind at some point in the future.

I'd be all for organizing a group like this with the mandate to release new versions. There is merit in streamlining this.

My head has been a bit stuck on point 5 though. How important is it for an ecosystem to let things die sometimes? Does the goal of keeping as much as possible alive and kicking end up just watering down the ecosystem? A dead module could also mean a leaner, meaner new module, which might help innovation. that wouldn't have existed if the old one was kept on life support without any intention to keep improving.

I agree that the approach proposed in #7 is very interesting. I might even volunteer to join such a group, if the community would trust me to do that. In the past, I didn't get involved in this d10readiness stuff for (supposedly) abandoned modules, because I usually have my hands full maintaining my own projects and I simply can't commit to maintaining such projects in the long term. However, just working on a release for the next major, maybe fix a few urgent issues, preferably for projects that I already use, and all that without joining as an official maintainer of the project, would work well for me. It would also be transparent to the community that people like e.g. @heddn don't have plans to maintain the module in the long term, but that this is a one-off gig.

I also know of a few projects where the maintainers just don't have the time "right now", but haven't actually abandoned the project and would appreciate such temporary help to get out a release. A few weeks ago I talked to someone from another agency, who maintained a module that was supposedly abandoned, and they really appreciated the offer by the d10readiness initiative to help get the release out, because they just can't work it into their schedule at the moment. If such a group existed, the DA might even send out a mail to all maintainers offering porting help and there could be a way for maintainers to explicitly request that someone from the group work on their module and take care of a release, which might make some things easier.

W/r/t #11.5, there are different ways to deal with that. If there are good alternatives that are well-maintained, one option might be to not release a compatible version, but provide an upgrade path to one of the alternatives. The difficulty with such an approach would be that existing maintainers might object to that, if the project is not really abandoned. Another obvious option is to come up with some kind of criteria on which modules to work on, which is already part of the proposal, because it is required for the governance part of the process. Finally, there is room for innovation even when such a group would create a compatible release, given that such a module would most likely be less than minimally maintained. So there is still an incentive for innovation, it might just not happen as quickly.

Nice idea: having a group for becoming maintainer temporarily just to create a release compatible with the next major. For the D10 readiness I have adopted two modules so far (with a third one in progress), but I have been holding off trying to adopt many more, because I don't know if have enough time 4-5 weeks later to act quickly. Even for the modules I adopted it took me about 2 months before I made the D10 release because other stuff got in the way during that time period (but also because I wanted to thoroughly test these modules myself first before creating the release).

Those following this issue may also be interested in the discussion in this related issue: #3377468: Can site moderators turn down an offer to maintain from a qualified candidate? → . Currently taking place in the Drupal.org site moderators' issue queue.

We should get the process in liner for all newer versions of Drupal, beyond Drupal 10. So we can adjust and improve the process, but not need to go through the whole setup every major version.

Encouraging the "parallel maintenance" of modules is an aspect of this to keep in mind— it should be endorsed and made as technically feasible as possible to have a module working in an issue fork, and easy for people to use an issue fork instead of the main module. Ideally this can be tracked.

This encourages contributing before getting maintainership, and no matter how much we streamline the process there will be a lag, and no case for getting maintainership is as strong as doing the maintenance already.