Document when project moderators can turn down an offer to maintain an abandoned project done from a qualified candidate

I think asking for clarity and motivation would be good.

I have seen some contributors want to keep the older project alive because the code is less bloated and serves their needs more than the newer project.

Actually, #3234825: extlinker project open to new maintainer applications on 30 Sep, 2021 is one of those automatic issues created to find maintainers for a Drupal 9 versions of those projects. It's not the normal procedure used to add new maintainers, as it does not require to wait 14 days for a reply from the current maintainers.

Since site moderators and project moderators just need to check whether the person who offers to maintain the project is able to opt projects into security advisory coverage (in the case the project is covered by security advisory policy), I do not see any reason to postpone those issues nor decline them.

Becoming a project maintainer is an excellent vehicle for gaming the credit system.

No, it is not. Credits on fixed issues are weighted by project's "importance." Credits on ten Drupal core issues have more weight than 20 credits on a project used by none or very few sites.

If then the reason for not accepting a maintainer offer is the fear of credit system gaming, people who are offering should not be asked why they are interested on a project nobody is using, which is totally irrelevant to know if they are really gaming the credit system.

Anyway, I think it is clear that when Drupal Association staff created the automatic issues for Drupal 8 projects to be ported on Drupal 9, the main point was not to delay those offers, which is happening for at least three issues just for the fact the offer came from the same person.

As for projects nobody use, if that would be a reason to postpone those offers, that should also be done for #3235167: content_moderation_reviewer project open to new maintainer applications on 30 Sep, 2021, which has been created for a project nobody uses.

It was an experiment initiated two years ago. The usefulness of this project for the health of the Drupal ecosystem is disputed.

If that were the case, you should not add as maintainer any person that uses one of those automatically created issues. It is not that is an experiment just when a person offers to be maintainer for three different projects.

No. It is not happening because the issue came for this particular person.

Yet, there are not limits to the number of projects a person can offer to maintain. That holds true for the expedited procedure like for the usual procedure.

the motivation of the person making the offer was given up-front

Truly, the motivation for a person to become maintainer of a project is not information that people who offer to maintain projects are required to give. I would understand if a person could be puzzled by being asked that when the same question has not been asked to many other people, and would not reply to that question.
It is not even an information that site moderators could insist to ask.

Truly, the motivation for a person to become maintainer of a project is not information that people who offer to maintain projects are required to give.

The template itself says Comment here explaining why you would like to maintain the module. I would contend this is asking users to provide their motivation and is indeed required as part of their initial request.

I (not a site moderator) always interpreted that as requiring a user to provide a reason the site moderators to review and make a judgment. I believe the expected responses were at the time predicted to be along the lines of "I have 3 sites that require this module", "I am the maintainer of module XYZ that uses this as a dependency" etc. I don't think it was expected that "I have no connection to this module at all and no explicit need for it on a site, but I want to take over maintaining it" would be a scenario that was going to be likely to occur.

Drupal 8 projects to be ported on Drupal 9, the main point was not to delay those offers,

A key point is it was intended to not delay projects so that could be upgraded before D8 went EOL or at worst allow a quick adoption after D8's EOL which occurred 3 years ago. The 'necessary speed' is in my opinion questionable now that D9 too will be EOL in just a few months. If these modules were being actively used I think we could expect they would of been adopted sooner.

If an applicant can not provide a reason as to why they want to adopt the module other than a generic "I want to update it" I think there is reasonable grounds to question the application especially when alternatives exist.

As @volkswagenchick points out, If an applicant can say "It does XYZ that module ABC's maintainer has said they will not implement" or "Due to ABC's larger size it decreases performance X% or adds Y milliseconds to each request" it shows both a display of knowledge of the inner workings of both modules, and justification for why they would be choosing to adopt the module over using a similar module that may have a more active user base.

If we look at #3357734: Lower the bar for module adoption for Drupal 10 we do have some notes of a user adopting a large number of modules through the ownership queue and than abandoning them without ensuring a clean transition. If we assume the site moderators have no authority to deny requests than said user would be allowed to do so again, if the site moderators do have the ability to do so than that would be an example of a behavior a moderator might want to consider and use as justification to deny a transfer which is part of the root of this issue, do the site moderators have that authority.

There was an argument on Slack that letting a user adopt an older abandoned module is better then them creating yet another duplicate, and there is indeed some truth to that. I know that before I had the security opt in permission I would be willing to fork a project if it didn't have an active maintainer to ensure that I could continue development if I couldn't adopt it, but that would be for modules I was either using at that moment, or was trying to implement into a site, not just because the module was available to be maintained.

You've lost me. I don't see why this is relevant to this at all.

It is relevant because there are four postponed issues where the same person commented. Since other people who offered to become maintainers for a single project have not seen their offers postponed...

The template itself says Comment here explaining why you would like to maintain the module. I would contend this is asking users to provide their motivation and is indeed required as part of their initial request.

There are other issues where the person did not say why the offer to maintain the module has been done, but those offers have not been postponed. Even if I would take that as mandatory, that does not mean that the offer should be postponed after the person answered that part, except in the case the reply was not appropriate (Because I want, for example).
Furthermore, the text says confirm that you have previously received security coverage opt-in permission even if user profiles show who can opt projects into security advisory coverage. Let's not use that text as excuse to postpone an issue when other issues have not been postponed for the same reason.

Finally, Do you have mind-reading abilities crosses the borders. I do not need mind-reading abilities because I am not reading minds. I just wrote facts: More than three issues where the same person offered to become maintainer have been postponed. Whenever that is intentional or not does not matter.

Instead of A better alternative already exists that is not abandoned I would add a case for people who offer to be maintainers, but that in the past removed themselves as maintainers for projects they offered to maintain.
Now that the Gitlab interface allows people to remove themselves from the maintainers/co-maintainers of a project, even people who do not have the Administer maintainers permission for that project, that is going to happen more often.

My suggestion after reading the comments would be as follows:

For a maintainership offer (or one of the automatically created bot issues) on a project that is truly out of date/replaced by another module:

• Close the issue 'won't-fix', with a comment that says "This project is obsolete due to [other module] or [core]. If you believe there is a reason to revive this module anyway, please reopen this issue with a detailed explanation the purpose this project would serve that is not met by the existing options that replaced it."
• Perhaps the issue title should have the word [Obsolete] added in front
• The project page should be edited to mark obsolete status and add a link to the replacement to the description.
• If the user does re-open and the explanation is good, proceed as normal with adding maintainership.
• If the user does re-open, but with no explanation or a bad explanation, we close again with a denial.

I feel like that will let us help key the queue clean and not spend too many resources on unneeded projects, and leaves enough discretion to you all as moderators to judge how special cases might fall.

I read all the comments here. None of the challenges to this idea were strong enough for me to disagree. I do think that the moderators should be empowered so they can maintain and improve the extension ecosystem. So, for me, the solution offered in #15 fulfills the intention given in the issue summary.

Does any one disagree with implementing #15?

As a side note, the first paragraph on How to become project owner, maintainer, or co-maintainer says:

If you are a developer who have been working in the issue queue 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.

(Emphasis is mine.)

I gather that means offering to be maintainer / co-maintainer / project owner should be done by people involved in some way in the project.
If I take that literally, it means that (as project moderator) I could decline an offer done from a person who is not involved in a project. It does not seem that the involvement on the project is a matter of maintainers' preferences. (Differently, that paragraph would not have been added.)

I do not disagree on comment #15, except I would not add [Obsolete] to the issue title. One of the issue statuses is Closed (outdated); that status could be used for those requests. (Alternatively, the status could be simply changed to Closed (won't fix).)

The scenario I believe you are alluding to where an owner agrees to an unqualified individual is being discussed in #3500263: [META|POLICY] Think of a way to make adding a (co-) maintainer more trustworthy.

I am referring to the issues moved to the Drupal.org project ownership queue, where the person who offers to be maintainer / co-maintainer / project owner has not been involved on the project issue queue in any way. I am not referring to issues where the person is added as maintainer / co-maintainer by the project owner, since in those cases project moderators do not do anything.

There is agreement on #15 on the process/overall plan.

I think there are two remaining task. One is to settle on, which is what, if anything, to put in the title. For me, that is an implementation detail that the site moderators can decide amongst themselves. And the other is to update the doc page. I have updated the issue summary with that.

Fixed typo in title

I changed the title to be a task description rather than a question.

Despite the title, which is more generic, the issue purpose is deciding who can ask to be co-maintainer, maintainer, or project owner for abandoned projects.

People could still take over a namespace, even if the project is abandoned. In that case, declining the request saying the project is abandoned and they should look for a different project is not possible because people who request to take over a namespace are expected to request it to create a different project, which could even have a different purpose.
I would rather not see people requesting to take over a namespace to be able to develop a project and avoid being said they should look for a different project.

As a side note, it's project moderators who handle offers to be co-maintainers, maintainers, or project owners; site moderators do not have the permission to add co-maintainers or maintainers. They would need to make themselves the current project owner to be able to add new co-maintainers/maintainers, while project moderators can directly add co-maintainers/maintainers because they have the permission to access the tab to add/remove co-maintainers/maintainers.

If the real issue is how many requests/offers people can do, which is what I gather from the first comments posted here, the issue summary needs to be updated because, in that case, the issue is not abandoned projects.

I would agree that people should not make many offers/requests in short time, especially after I saw people offering to be maintainers for projects using issues tagged Project available for adoption, who then removed themselves from the project maintainers.

Actually, rescoping after all these comments would invalidate all the comments.

The example given in the first comment is not a good example, since the purpose of the issue tagged Project available for adoption was to make easier to be appointed maintainers and avoid a project would be automatically marked unsupported because no release existed for any supported Drupal version.

Declining the offer to become maintainer, co-maintainer, or project owner for a project that is considered abandoned is a bit controversial.
People create a project on drupal.org because they want to share code. They do not create a project because they know the project would still be relevant after four Drupal versions, for example; they do not create a project because they know X sites will use that project.
If somebody else still finds a project useful after its maintainers stopped to maintain it, or simply wants to create a new project using an existing namespace, they should be allowed to develop that project.

When the procedure to appoint new maintainers, co-maintainers, or changing project owners was created, it was not expected that a single person would ask to maintain many projects in few weeks. Probably, it was expected that people would offer to maintain a project they were using.
There should probably be some limits on how many offers a person can open, and the conditions under which a person can create an offer, but those conditions should be very specific, and not as generic as "the project must not be abandoned."

Question:
Where would the decision from this issue be documented? My understanding is that 'How site moderators handle requests to be project owner, maintainer, or co-maintainer.' is not a policy document (and that this is a 'policy documenting' issue).

Since the purpose of this issue is to [d]ocument when project moderators can turn down an offer to maintain a project done from a qualified candidate, that can be done by changing the only document that describes how project moderators handle the offers/requests to be maintainer, co-maintainer, or project owner.

The component value used for this issue does not mean a policy is going to be created. It simply the "best" component value which could be used for this issue, without using the too generic Other, and without creating a new component value.

Projects could not get commits from the original maintainers (which essentially means the project became abandoned) because:

• They are no longer involved in writing code
• They are no longer in an organization involved with Drupal
• They wrote the project for a customer's site, but the customer then decided to close the site, or decided to use a different CMS
• They created the project to share their code, hoping somebody would then further develop it

None of those reasons is a reason for somebody else to not maintain the abandoned project.

A project for exactly the same use case with a stable release is not a reason for not offering to maintain an abandoned project. There could be reasons for maintaining the abandoned project, for example:

• The other project could also be abandoned, despite having a stable release (There are abandoned projects which have stable releases, even for Drupal versions no longer supported.)
• The other project could have dependencies the new maintainer thinks are not necessary, or that make developing the project harder
• The other project could depend on third-party code which is no longer maintained, and which forced the Drupal project's maintainers to fork the third-party code and maintain the fork together the Drupal project
• The dependencies for the other project are not compatible with the dependencies of a new Drupal version
• The implementation of the other project is too complicated for the purpose it has, while the abandoned project is easier to maintain
• The other project could be rewritten to depend on a Drupal core module, but rewriting the abandoned project is easier
• The maintainers of the other project already declined offers to be maintainer, even when the person who offered to be maintainer created issues for the project and provided patches / merge requests

The issue summary speaks of abandoned project, but then a comment lists as reasons to not accept an offer to maintain a project:

• The absence of involvement in project issues by the person who offered to maintain an abandoned project
  That would be a reason for declining or postponing a offer to maintain/co-maintain any project, not just abandoned projects.
• The automatic Project available for adoption issues are useless
  Those issues were created for any project without a Drupal 8 release, not just abandoned projects. They are no longer used, but they have been helpful in some cases; they are far from being useless, even if the number of projects with a Drupal 8/9/10/11 release created by a maintainer added using one of those issues is probably less than the number of projects expected to get a release for supported Drupal versions.
• Becoming a project maintainer is an excellent vehicle for gaming the credit system
  For abandoned projects (for which this issue has been created) the credits have the same weight they would have for a new project; that is because, in most of the cases, abandoned projects are not used from any site, or the number of sites using those projects is very low.
  Truly, I have seen more new projects used to get issue credits, although their weight is low or very low.

I am closing this issue as per my previous comment.