what is the status of unconf packages?

[maelle]

Should unconf packages be in the registry? E.g. codefinch, miner... They're out-of-scope and community-contributed but live in an rOpenSci organization.

[sckott]

we do have this in our poliicies document though

Note that not all packages developed internally by rOpenSci or through our events or collaborations are in-scope for onboarding process.

[maelle]

Yes, I was wondering whether they had a special status (like a third category?).

[maelle]

I see unconf packages like e.g. available are shown on the website. So should there be a property in the registry or a value of say the property contributor (community vs staff currently)? Or should they not be shown on the website and not be included in the registry?

[sckott]

well available didn't go through review, but is on cran, so thought it was worth including in registry.

We might want to have a category for unconf pkgs that haven't gone through review

[maelle]

colorpiler is another example of an unconf package that's on the website.

[maelle]

What about having a value depending on which unconf it was created in? I.e. the property "origin" has these values:

• staff

• community

• unconf15, unconf16 etc.

• ozunconf16, ozunconf17

[sckott]

@maelle i like that idae, sounds good to me

[maelle]

I'm wondering whether the unconf names could be keywords in DESCRIPTION, e.g. "unconf17" for available 🤔

[sckott]

Does make sense to have unconf + year. I guess we don''t have a way to do keywords in each codemeta file ourselves. That is, they have to come from the package itself, yes?

[maelle]

Yes!

[maelle]

Added a GitHub topic to all "unconf repos" I could identify by date of creation in ropenscilabs. This excludes repos created in ropensci for unconfs prior to 2016 of course, and is not a perfect approach.

In any case codemetar will get the topics as keywords in codemeta.json so we can filter/compute the unconf status from that.