Package status tags

[noamross]

Here are fields we need in the registry to implement the Package Curation policy

Boolean or tag fields:
staff for staff-maintained packages
peer-reviewed for peer-reviewed packages
archived for packages (will be moved to new ropensci-archive namespace)
incubator for packages in ropenscilabs (to be renamed ropensci-incubator, I guess we could also just stick with labs. Either will just need documentation everywhere).

Also:
archived-date - date for archived packages
archived-to - URL of repo for where archived packages are moved to

We will use this to:

• Convey archived status to packages when they are retired
• Identify packages that are neither staff maintained nor peer reviewed, to return to author GitHub namespaces
• Provide more info and filters for the Packages page on the website
• Exclude archived and incubator packages from regular maintenance/status checks

[sckott]

thanks for opening this @noamross

@maelle what, if any of these fields, would/could be integrated into codemetar? Or do we do all of these outside of the context of codemetar? And do the below notes make sense to you?

Some notes on the fields (checked box means I think we have all necessary info already):

• staff: if we don't have already, maintain a text file with staff names - then flag as true if maintainer is in that list, false otherwise
• peer-reviewed: we already have this information in the onboarding field in registry.json
• archived: can probably automate detecting this if we are pulling info from all ropensci orgs (we should document this to make sure everyone knows this does not mean CRAN archived; although if its archived here, most likely it's CRAN archived)
• archived-date: ideally we automate this - could be the first time it's detected in the ropenesci-archive github org
• archived-to: should be easy to use the new url, e.g., https://github.com/ropensci-archive/foobar
• incubator: simply flag as true if in ropenscilabs, false otherwise, can automate easily

[maelle]

To me it seems these are fields that should be handled outside of codemetar.

Some further comments:

staff: if we don't have already, maintain a text file with staff names - then flag as true if maintainer is in that list, false otherwise

It might be a bit more complicated depending on when staff members developed the package. 😉 But yeah the staff list, that you can retrieve from https://github.com/ropensci/roweb2/blob/master/data/team/team.json, is probably a good approximation.

Reg archival date, if I remember correctly, I looked into this when Noam asked a question about it in the curation policy, and couldn't find any way to retrieve the information via GitHub API so yeah it'd be good to collect the date ourselves.

[sckott]

thanks @maelle

[maelle]

archived: can probably automate detecting this if we are pulling info from all ropensci orgs (we should document this to make sure everyone knows this does not mean CRAN archived; although if its archived here, most likely it's CRAN archived)

We might actually want 3 archived fields

• archived on CRAN
• transferred to ropensci-archive (how do we get this info? it means you'd treat ropensci-archive as ropensci and ropenscilabs, cloning all repos?)
• archived on GitHub

[sckott]

right, github_archived and cran_archived already done - although github_archived needs some fixing as it doesn't account for repos transferred to ropensci-archive yet. I would think for github_archived it would be true when a repo is in ropensci or ropenscilabs and is archived OR is true if its in ropensci-archive (and is github archived or not, doesn't matter) - otherwise github_archived would be false

[maelle]

What's important for me is having a single variable that'd determine whether the packages is shown in an archived tab on the website packages pages.

One case I can't remember: if an ropenscilabs repo isn't transferred to its maintainer account, where does it end up?

[sckott]

if an ropenscilabs repo isn't transferred to its maintainer account, where does it end up?

i don't know 🤷

[maelle]

@noamross what do you think?

[maelle]

re-reading the beginning of this thread, reg "Identify packages that are neither staff maintained nor peer reviewed, to return to author GitHub namespaces" how would we even track a repo that's been transferred back to their author org? We'd need to store the URL and status here?

[maelle]

Maybe if authors opt to have the repo transferred to their own account they can't expect us to keep listing it on the website? I am worried to introduce more complexity to the build systems for a few exceptions that don't even exist yet.

[sckott]

i guess we just add a url to this text file https://github.com/ropensci-org/makeregistry/blob/master/inst/automation/not_transferred.txt right?

[maelle]

But we'd need to record status in case authors don't add the badge

[sckott]

true - is there a default status we could use for all repos in those cases? just use Active?

[maelle]

well that's what we do now, but if we start letting authors have their repos move to their account instead of ropensci-archive then we need to track the status.

[sckott]

Can we make sure they have a repostatus badge before transferring the repo?

[maelle]

can you add this to the dev guide PR?

[sckott]

I assume you mean the PR that you just merged?

[maelle]

yeah, I added that so my request was outdated, sorry

[sckott]

isn't this already done here -> https://github.com/ropensci/dev_guide/blob/dev/maintenance_curation.Rmd#L201-L202

[maelle]

what's still missing here is "archived-date". @noamross do you remember why it was needed?

[maelle]

👋 @noamross

[noamross]

I can not recall a specific reason that we would use this but I think such a record is a good one for future (un)anticipated analyses (e.g. "how long do packages go before archiving?").

[maelle]

Now I realize I have not stored archival dates so I'll try and explore GitHub API 😬