Suggestion: email maintainers of packages not updated for a long time with a lot of issues about package-maintenance HOT 7 CLOSED

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.

from package-maintenance.

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.

from package-maintenance.

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.

from package-maintenance.

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.

from package-maintenance.

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.

from package-maintenance.

@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?

from package-maintenance.

I am fine with closing it for now.

from package-maintenance.