Checking for multiple active maintainers when accepting a project
doesn’t necessarily mean it will always stay that way, so you
similarly need to decide what you do (if anything) when the active
maintainer count falls below the acceptable threshold, and who will
be checking for that and how often.
However, I’ve seen plenty of projects go from lots of active
maintainers to approximately zero overnight, if they were all using
it in the same organization and suddenly business plans changed, so
it can be useful to think beyond simple maintainer count and
consider affiliation diversity as well if you think it’s an
important risk to mitigate. And even then, it’s the sort of thing
that can change over time, I’ve also seen my share of projects go
from being maintained by people from many organizations to only a
few, and then one, and then… none.
To note, the one benefit of a project being under the PyPA org to begin with is if worst comes to worst and all the maintainers abandon the project, there exists at least the capability for another trusted PyPA member interested in picking up maintaining it to be added, or other actions taken (of course, they presumably wouldn’t have the PyPI keys unless they were stored as org secrets or there was a PyPI abandoned project request, but they’d at least have the source and the community and could reclaim the project name once sufficient time had passed).
Whether the PyPA would be willing to do that is, I presume, not a settled question, but it’s at least possible. Kicking someone out of the PyPA if they don’t maintain a maintainer threshold is, in a way, actively counterproductive to the goal of reducing long term bus factor as the projects who could most benefit from org rather than personal ownership won’t have it.
ok i hear all of you - bad idea on my part i am still learning the dynamics of this community here and by no means want things to move backwards !! It’s great to better understand what the challenges are.
And also you’re right @fungi - a maintainer team could also step down at any point in time and it would be really hard to in general to support such an idea. ok i (unintentionally) drove this conversation in the wrong direction!
It’s not a bad idea, it’s just that there’s a lot of “been there, done that” sentiment that means people tend to resist reopening topics that have been painful in the past. A fresh viewpoint is very important, and it’s entirely possible we should do things like this, it’s just hard to work out how
Right, I spend a lot of my time in another large open source
community that does try to take things like active maintainer count
and maintainer affiliation diversity into consideration (also if
you’re into those sorts of sustainability topics, maybe check out https://chaoss.community/ since they’ve got lots of people who work
on finding ways to measure and analyze such things). I just wanted
to make it clear that it’s not as simple as having a “bus factor”
requirement, and there is necessarily a lot of work involved in
implementing those sorts of policies as well as impact trade-offs
that have to be weighed.
The idea is not bad on its own, but it sounds like it may not be a
fit for PyPA (and would, I’m sure, need a lot of discussion).
Well, isn’t there an alternative solution, which is just to create some sub-organization of or parallel organization to PyPA that is not bound by the existing requirements, and then have that do what @lwasser suggested?
Or, let me put this another way: What, currently, is the benefit conferred on a project’s users or maintainers by having that project be under the PyPA umbrella? And which of those benefits are intrinsically tied to being under the PyPA umbrella, and cannot be obtained by being on some other “list of projects” that is not subject to the governance constraints you mention?
i am still learning the dynamics of this community here and by no means want things to move backwards !! It’s great to better understand what the challenges are.