[META|POLICY] Think of a way to make it less easy to become a (co-) maintainer

Re-titling. It seems important to focus on the goal (safer additions) than a potential solution (harder additions). It's possible a solution will be that it is somewhat harder to be added as co-maintainer, but just making it harder alone doesn't make it safer.

Maybe a checklist could help?

1. Are they verified
2. Are they part of a company on the community radar for concern?

And there may need to be some governance around if the DA can remove someone. If a maintainer isn’t paying attention and adds such a user, like your example, and they do something that impacts 35K sites. DA should remove them till criteria is met.

If it's technically possible, we should disallow adding users that are not yet verified as a maintainer of a project.

There are docs pages already, we could definitely add some suggested items to the template. I'd be more +1 to the idea of using "git verified" as a hurdle if that process were more efficient and transparent to end users (e.g. a quiz, being able to apply with significant MRs to core/contrib).

Just to be clear, by "not yet verified" I don't (necessarily) mean git verified; I was thinking more about this "NEW" status:

I'm not sure how that's reflected in d.o's schema but looks like the proper term is "unconfirmed":

https://www.drupal.org/drupalorg/docs/user-accounts/become-a-confirmed-user →

Adding a user with that status as a maintainer seems fairly bonkers, to use a technical term.

Re #4

2. Are they part of a company on the community radar for concern?

I don't think that's really a trustable check. I can create a new account and register myself as an Acquia employee on Drupal.org. There is no check involved here. I remember seeing an issue about this somewhere to allow orgs to enable a setting that they have to verify users.

Ah, that makes sense. +1 to that as a base level.

Personally I've generally asked applicants to go through the queue and post patches to the things they are likely to fix first, to provide feedback on proposed feature issues of whether an idea fits with the philosophy of the module or not, to do reviews of patches other people have provided, to create a "next release" plan issue and highlight what they would commit in that next release. Those create more material for the current maintainer to at least skim over before granting access. They would also get the person past being "new" without using that specifically as the barrier.

Filing as a child of 🌱 [META] Increase Security of Project Ownership Transfer Process Active

Regarding #4 and #8
📌 Add ability for organziations to manage/approve contributors(employees) Active was opened to require orgs to approve users, it was rejected by Drupa Infra and narrowed to only allowing them to self delete users.

This hasn't really anything to do with project ownership transfer, which is only really used for abandoned modules if I'm not mistaken. But it for sure is related 🙂.

I'm following 📌 Add ability for organziations to manage/approve contributors(employees) Active so also related, but no the issue I had in the top of my mind 🙃 I'll check tomorrow if I can find it.