These packages are a community good, but maintained as a community service.

It's definitely best practice to have a few maintainers but this isn't the venue. One should contact the existing maintainers directly and ask to become a co-maintainer.
Unless the maintainer becomes demonstrably absent it is against policy to interfere in the current maintainers' approach. If a package lacks co-maintainers and/or refuses them, is slow to apply fixes, etc, one should probably fork the package or choose another.
The only real exceptions to this are core packages as under the maintenance of the CLC. Anything else would be a discussion about a massive change in policy.

 -davean

On Wed, Feb 17, 2021 at 3:33 PM Sven Panne <svenpanne@gmail.com> wrote:
Am Mi., 17. Feb. 2021 um 21:19 Uhr schrieb Thomas DuBuisson <thomas.dubuisson@gmail.com>:
I know, right?  I thought I addressed that - happy to wait a few weeks to see if the maintainer comes back on line (that makes it well over a month) [...]

Regardless of how urgent issues might be for you, I think that a lag of "a few weeks" is totally fine for any project out there maintained by somebody who does this in his spare time. You can be on a longer vacation, be ill for a few weeks, have something urgent things in your family/"real" work, and when you come back you suddenly have a co-maintainer you perhaps don't want? Have a release with some fixes perhaps going in the wrong direction? I would be extremely annoyed by such actions, and I'm sure I'm not alone with this. Doing such harsh measures in such a short time span is probably doing the project more harm than good.

If you really need a fix quickly, just fork the project and build from there for a while... Note: The last release of the packages in question is not even a month ago.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries