When should packages graduate from ropenscilabs to ropensci?

rOpenSci has two GitHub organizations: https://github.com/ropensci and https://github.com/ropenscilabs (hereafter, ropensci and ropenscilabs)

ropenscilabs is a more recent addition, and is meant to hold more nascent projects - projects that are in earlier stages of development.

Community contributed packages that go through software review via https://github.com/ropensci/onboarding AND all new packages we internally create go into ropenscilabs.

At some point we move packages in ropenscilabs to ropensci. However, we haven’t yet determined what that point is. If we all used package versioning consistently we could say at v0.5 for example we move to ropensci. But versioning is not consistent across packages. We do strongly recommend following semantic versioning https://github.com/ropensci/onboarding/blob/master/packaging_guide.md#-versioning


Question for everyone

What should the point be at which we move packages from ropenscilabs to ropensci?

1 Like

Hey,

Maybe there should be something like a time span of stability. The idea
would be that a package shall wait at least half a year within the labs
before considering moving it out. If it is then considered stable enough
and mature it can get out. Otherwise it should be discussed which actions
might necessary for the package to be considered stable.

Best, Peter
Am 15.06.2016 8:44 nachm. schrieb “Scott Chamberlain” <discuss@ropensci.org

I like the ~6 months of functional stability idea. Some potential criteria to look at after six months:

  • R API has remained stable
  • User-raised issues have been promptly addressed as they come up
  • CRAN/BioC submission has occurred if it was intended and maintenance has kept up with CRAN/BioC

It would be helpful to revive the package dashboard (formerly status.ropensci.org). It could include whether a package is in labs or not, on CRAN or not, download statistics, web view membership, Travis build status, etc. I think this would be good for keeping track and managing packages ourselves, but especially to help discovery. It also means moving from labs to the main repository would be a “badge” that authors could aim for.

I’ve been thinking of how this should be presented to users (not to developpers): for instance now on this page http://ropensci.org/packages/ there are badges for Github, CRAN and a “early development” label. How would ropenscilabs vs. ropensci be advertised & explained there? I would not really know what to do with the current “Others are in various stages of development (bleeding edge packages are not listed here) and you can learn more by following our GitHub organization page, and our GitHub organization for bleeding edge projects.” How would an user know how much they can trust a package that is in one of the organizations?

Then when one goes to a new repo one should look at the issues for knowing how much is going on, but it can be quite hard / overwhelming. Maybe when a package gets accepted into ropenscilabs the author and the reviewers/editors could agree on a small list of next steps that could be added to the readme with a link to issues? Or a sentence explaining how to see issues related to the milestone “ropensci”?

I just noticed that EML does not have the “in early development” label by the way. :wink:

It doesn’t seem like you need to have super strict rules here. Wasn’t gmail in beta release for ~10 years? Perhaps you set a couple of OR logical indicators, any of which indicate it might be time to transition to ropensci:

  • stable API
  • package downloads/usage
  • version bump above some threshold
  • issues mostly feature requests rather than bug reports
  • etc.

One thing to consider, I suppose, is how to handle web service packages. The package itself might seem ready for promotion but if the service’s API changes down the road, that could cause significant changes. I’m not sure this is really important, but it might require extra caution in promoting such packages.

nearly have an ropensci API ready, will have all those things you mentioned, with up to date travis, appveyor, downloads, etc.

Good idea, maybe let’s open an issue in onboarding for that telling folks that’s to come

@maelle

Good question. We could simply have a small icon for all pkgs within ropenscilabs, like Flask Icon | Font Awesome with explanation at the top of the page what that means


I too like the time span, 6 months seems good. Seems like the consensus is to have a variety of criteria, then after the 6 months evaluate whether enough (at least 1/2/3?) of the criteria are met to move to ropensci

For the time requirement, in hopes of automating that step: tried to find a github API call to get transfer date, but doesn’t look like that is easy to get. Closes thing I found is searching like https://api.github.com/orgs/ropenscilabs/events?page=2 and looking for events of type CreateEvent with the repo name you’re looking for.

In onboarding we could list the criteria that will be looked at after the 6 months. And perhaps indicate that someone can open an issue in the repo some time after 6 months to discuss whether criteria have been met or surpassed - after transferring, will apply the new badge discussed above

Woo!

What do people think of an RO status badge for the top of READMEs, with something like “rOpenSci | labs” and “rOpenSci | main” versions. If we use this, should we still have the footer?

1 Like

For the record, package curation policy.