I am currently working on an ecosystem-wide audit of the JuliaHealth organization as part of a NumFOCUS Small Development Grant. One part of this work involves summarizing the maintenance status of packages in a way that’s informative but not misleading. I would love some community input to better finalize the terminology and criteria.
Context
In the audit, we initially experimented based on last pushed_at status with labels such as:
Active
Inactive
Maintenance mode
However, after discussion with my mentors, it became clear that terms like “inactive” can be misleading in an open-source context. In particular, some Julia packages may:
Have low commit frequency
Have few or no open issues
Receive updates only occasionally (e.g. once a year)…but still be:
Stable
Widely used
Functionally complete
Well-covered by CI
In these cases, low activity does not imply abandonment, it may simply reflect maturity.
Questions
What terminology feels appropriate for categorizing packages in terms of maintainence level?
What criteria would you associate with a “healthy but quiet” package?
Are there any existing conventions, metrics or prior discussions in the Julia ecosystem that you think would be useful to follow or align with here?
This is purely for high-level ecosystem reporting and discovery, not as a judgment of package quality.
Thanks in advance for any thoughts, I really really appreciate the community’s perspective here!
The terms/definitions in repostatus are pretty clear / useful IMO:
Project Statuses
Concept – Minimal or no implementation has been done yet, or the repository is only intended to be a limited example, demo, or proof-of-concept.
WIP – Initial development is in progress, but there has not yet been a stable, usable release suitable for the public.
Suspended – Initial development has started, but there has not yet been a stable, usable release; work has been stopped for the time being but the author(s) intend on resuming work.
Abandoned – Initial development has started, but there has not yet been a stable, usable release; the project has been abandoned and the author(s) do not intend on continuing development.
Active – The project has reached a stable, usable state and is being actively developed.
Inactive – The project has reached a stable, usable state but is no longer being actively developed; support/maintenance will be provided as time allows.
Unsupported – The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired.
Moved - The project has been moved to a new location, and the version at that location should be considered authoritative. This status should be accompanied by a new URL.
I like the distinction between the development state and the current level of support. It might be hard to determine stability automatically since many julia packages like to spend forever before committing to a 1.0 release (many packages are very usable well before then), but nevertheless seems like a good level of granularity to me.
In terms of package health it may be useful to look at time-to-pull-request-merge as well, because there are quite a few packages I can think of where no one will merge a PR because there is no one who feels confident to review a PR - or because there are maintainers but they take quite some time to reply as well. These kinds of packages might be stable and broadly working but it is very hard to get a PR actually merged.
In terms of repo-status, this list fails to make the crucial distinction between:
Unsupported – The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired. The author(s) / owners are still responsive enough to hand over control to a new maintainer.
Unsupported/Abandoned – The project has reached a stable, usable state but the author(s) have ceased all work on it. The authors are not responsive enough to potentially hand over control to a new maintainer (maybe they are all dead and their heirs don’t want to deal with recovering github credentials). Any future work/maintenance must happen in a fork, and there will be no help in coordinating on the fork.
One cannot rely on author(s) to mark whether the project is “Unsupported” or “Unsupported/Abandoned” (but sure authors could mark that status!).
Instead, one would need some measure of “last time any person with control over the repo / commit rights has interacted with github”, either on any project, or on the specific project in question. And one would need a keep-alive: Ask authors to confirm 1-4 times a year that they are still alive.
One further consequence of this distinction would be: For Unsupported / Abandoned projects, the registry is responsible for changing the “project name / UUID”->“github project” pointer over to a fork (if a new maintainer materializes). There must be a clear process for that.
More important than maintenance status is the current list of maintainers. This information should be readily available to any potential contributor. It is very hard otherwise to get things going without someone accountable for merging PRs.
It took me years to register a package because I did not like the (then) way there was no way to “decomission” a package once registered. It did not need a registered package to disappear – although that would have been best on rare occasion. I did, and still do, need a simple way to let anyone who trys to install a given package that the package is one or more of (a) unmaintained (b) [please] do not use. Then have the user need to install it a second time before getting the code transferred.
In addition to looking at the project status on github you could see how frequently the package is downloaded from the Julia registry. Then packages won’t get a reputational ding if they are still used but don’t get, or possibly require, a great deal of maintenance.
