Can site moderators turn down an offer to maintain 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.

See this issue #3234825: Offering to maintain External Body Linker → for an example.

Actually, #3234825: Offering to maintain External Body Linker → 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.

I do not see any reason to postpone those issues nor decline them.

Well, I respectfully disagree. I can see at least three reasons to postpone some of these issues in order to ask about motivation – and to decline the offer if the motivation is lacking, or the motivation is not good:

1. I believe it is bad for the Drupal ecosystem to have a number of different projects providing for the same use case. It furthers competition, rather than cooperation (which is something that goes against the ethos of free software and the Drupal community), and spreads scarce resources thinner. I think we, when carrying out or duties as site moderators, should steer those offering to maintain these abandoned projects towards helping out maintaining the project that exists and that is already actively maintained.
2. The usefulness of these automatic issues created to find maintainers for upgrades from Drupal 8 to Drupal 9 are disputed. It resulted in at least some projects being adopted by some people not sufficiently motivated to actively maintain the project. The DA has decided not to create a similar scheme to facilitate upgrades to Drupal 10.
3. Becoming a project maintainer is an excellent vehicle for gaming the credit system. because a maintainer can give issue credits to themselves. This is one of reasons I think I agree with volkswagenchick that we need to be sure about the motivation being right.

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 of 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.

If then the reason for not accepting a maintainer offer is the fear of credit system gaming

It was only one of the four reasons given. The major reason for postponing is the first one: Fear of doing damage to the Drupal ecosystem.

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

It was an experiment initiated two years ago. The usefulness of this project for the health of the Drupal ecosystem is disputed. The comments by cmlara and others in this issue 📌 Lower the bar for module adoption for Drupal 10 Active significantly cooled my enthusiasm for this experiment. Anyway, Until the DA comments here, we don't know how they feel about it being expedient to revive some of these abandoned modules today.

which is happening of at least three issues just for the fact the offer came from the same person.

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

1. A better alternative already exists that is not abandoned.
2. The person offering to maintain has shown no prior interest in the project.

That these offers came from the same person is pure coincidence.

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.

It is not even an information that site moderators could insist to ask.

Well, IMHO, that is not as cut and dried as you seem to think it is.

I created this issue to discuss this. If you are not interested in this discussion, that's OK with me, but I am sill interesting in the viewpoints of others on this topic.

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 📌 Lower the bar for module adoption for Drupal 10 Active 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 issues where the same person commented that are postponed. 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.

Yes, it is a fact that more than three issues where the same person offered to become maintainer have been postponed.

But the phrase "for the fact" is not only stating this fact. It stating that I decidced to postpone said issues because of this fact, which is false.

I think we can agree that posting multiple offers to maintain is not a valid ground for postponing processing the offer.

I have already stated what I believe are valid grounds for postponing these four issues in order to ask the person to explain why they would like to maintain the module. Here they are those grounds again:

1. A better alternative already exists that is not abandoned.
2. The person offering to maintain has shown no prior interest in the project.

In the past, it is true that our policy has been to automatically add maintainers to abandoned projects if they qualify. I think this policy is not the best one for the health of the Drupal ecosystem, and want it changed. That is why this issue has the component "Policy".

Finally, it is true that today, user profiles show a tickmark visible to all if the person can opt projects into security advisory coverage. That was not the case three years ago, when these automatic issues were generated.

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?