What are people’s thoughts on retiring packages?
We’re discussing the package rdopa right now https://github.com/ropensci/rdopa/issues/26
As far as CRAN goes, we simply have the package maintainer ask CRAN to archive the package on CRAN.
For rOpenSci, do we have some official badge or so about this? I’ve personally stopped maintaining a few, and have just updated the README saying so and archived on CRAN - but is there something better we can do?
cc @jlehtoma
I think we should at least add/update the appropriate repostatus.org badge
to the package README (e.g. either inactive or unsupported),
http://www.repostatus.org/
Ideally some documentation of why the package has been sunset should be
included as well, perhaps in NEWS and/or more prominently in README.md
(e.g. maintainer no longer active vs some API service that no longer
exists, or if the package has been deprecated in favor of a more recent
tool or approach etc).
codemetar will also pick up repostatus badges, so this information would
then be available in the roregistry records and could be appropriately
reflected on the packages page of our website as well.
While this seems like the right way to retire a package, I think we should first have a decision process as to whether we should retire it. RO asserts the right to step in as maintainer of last resort if an author neglects maintenance. This means we are deciding which neglected packages are worth maintaining. Some questions we might ask in this decision:
In this specific case it seems to me like the package serves a clear use and is tied to a system supported by (apparently) the EU, so it seems worthwhile, if under-maintained.
As I was looking at it I was wondering if within rOpenSci there could be a tier of packages for which the maintainer has clearly stepped away, where community members with less experience might be more willing to step in and assist.
I would suggest that given the response, the maintainer was unclear even if the API existed in the form that was wrapped. Perhaps that could be a last-resort test for package maintenance & retention. If the API no longer functions as expected & the maintainer has stepped away it goes into a ‘retired’ section?
@cboettig totally agree about
update the badge
updating README text
documentation of why the package has been sunset in NEWS/README
@noamross Right, good idea to have a discussion about if first. Would be good to agree on and add some text about decision process to perhaps this document https://github.com/ropensci/onboarding/blob/master/policies.md
Anyone else have thoughts on the list of things Noam suggested?
@SimonGoring Agree that the topic of the data does seem like it’d be useful to people and not too niche. Good point about thinking about if the data source is down, etc. I do agree with Noam though that we should consider a number of things for each case. Of course if the data source is completely gone away, there’s not even an option of continuing work on it
I agree with Noam that retiring a package should start questions about what role this software currently plays. How many people use it, what are likely issues with the software disappearing, etc? There are also different reasons why a software could go into this mode:
The package was primarily an API package. That API has now disappeared, so without that input hose of data, the package can do nothing further. In this case, repostatus badge, archive on CRAN, and possibly also Zenodo. This is important because if any papers depended on this software and someone had questions on how the data was processed, they could refer to the archived code to discover any problems or artifacts.
If the issue is that the maintainer is no longer interested, then we could move it to a maintainer-wanted status and advertise that to others from that domain who may have an interest. Until then, it goes into holding.
If a package is a critical piece of rOpenSci infrastructure, then rOpenSci staff will take over maintenance, or actively hire a contractor for the process. But this determination will have to come from the staff. With the growing number of packages that are user contributed, we have to make the determination on how best to proceed on a case by case basis.
I’m not sure whether the API disappeared or was just reorganized. Maybe @jlehtoma can clarify with what he knows. Given that the package maintainer doesn’t have capacity and the major change, that there are no reverse depends and AFAICT the package is not functioning in current state, I think retirement is reasonable.
If updating for a reorganized API is what is needed, this could be a neat project for an eager new volunteer package author who wants to learn, and we could put out a request to see if someone wants to take it on. I also note this package predates current onboarding practices, so a new volunteer could take it through the whole process.
Agreed.
The outcome that we see more often is that a service no longer wants to support an API. If that’s the case, and the primary functionality of the package was to read and process data from the API, then retiring the package seems like the most logical outcome (with code archived somewhere for posterity).
Just to add one more package to the mix, dvn is basically retired. I theory it still works and doesn’t need to be CRAN archived (because it could still work with legacy installations of Dataverse) but there will be no further updates because new Dataverse installations use a totally different API and therefore have their own package.