Suggestion: email maintainers of packages not updated for a long time with a lot of issues

[io4]

I suggest automatically emailing maintainers of packages that have multiple issues (to avoid emailing packages that do not need updating such as left-pad), but the last release happened months ago.

The email should suggest them that they should either deprecate the package, or find another maintainer (suggesting organizations willing to take care of packages with many downloads per day such as Code Shelter, or suggest them using the method described in #4 ).

This email should only be sent once.

[ljharb]

I’m not sure automating this would be useful - i have plenty of packages that i actively maintain that have a bunch of open issues. They could be feature requests, or bugs that can’t yet be reproduced, or just discussions or q&a threads, or things that have a “help wanted” label but i don’t have time to do myself.

[io4]

That's why its a single email. If you consider the actions suggested are not required, you can ignore it.

It believe my suggestion will be useful to some people, but of course not everyone.

[ljharb]

I think a single email that implies that i need to find a new maintainer when I’m actively maintaining a package would come across as arrogant and rude and offensive to me.

[io4]

Maybe it can be done the other way, email voluntaries with a list of packages that might need maintenance, and handle it like github discover does (send a list of for example five packages so they can consider if they want to help the maintainer with issues, take other actions such as contacting the maintainer, and make the frequency of the emails variable).
Of course the voluntary is not going to help with all of them (either because they cant help because they dont have experience in the frameworks or dialects used, they consider help is not needed, or dont have time for large tasks).
The idea is promoting mostly single-time help and sometimes long-term commitment from the volunteers.

[mhdawson]

I agreed with @ljharb that we have to be careful of adding to the burden of maintainers. I think we probably want to start by figuring out what works, what is useful to maintainers and then once we believe we understand that look at if automation might help.

[mhdawson]

@io4 I think we want to start by understanding how we can help module maintainers and doing things manually before we look at trying to automate the identification of problem modules which could be quite controversial. Would it be ok to close this issue, and then have you raise it again once we are further along our learning process?

[io4]

I am fine with closing it for now.