Identifying packages in need of maintainers

I’m thinking about a potential extension to PEP 541.
I’ve experienced related problems from the maintainer and user side:

  1. I maintain package X but I just don’t find much time for it. I’d love to get someone’s interest in contributing and becoming a co-maintainer. Where and how do I advertise this?
  2. I use package X (maybe as a third order dependency, so I’m not even aware that I’m using it at first), but it has an issue which starts causing problems. e.g. A new version of Python releases and the package no longer works. I find that the package has been abandoned by the maintainer. I don’t want to become the new maintainer, but I’d like to flag this.

I feel like I’ve been seeing more and more packages abandoned in the past couple of years. Maybe that’s just a quirk of my experience, or maybe part of a broader trend.

Being asked to take point, as the reporter, in trying to contact the maintainer (a la 541) seems okay to me for case 2.

The thing I don’t have a great idea about is where the data goes or how it’s made visible. My thought was to have something like the Jenkins community’s Plugin Adoption Program.

Is this interesting to others? I’d love to bat around ideas for how to do it and would be willing to try to write a PEP (I have never written one, but can learn). I don’t think packaging metadata is appropriate because it can’t handle both scenarios.

2 Likes

In both cases, the package’s issue tracker is probably the best place, that’s where people tend to look in the first instance.

I’ve seen posts like this for both cases, and have seen successful outcomes:

  • (1) is often easier: new maintainers volunteer and the old maintainer adds them to the project
  • (2) can also result in new volunteers joining the project. Although sometimes the old maintainer is uncontactable and a fork may be required.
2 Likes