rrlite

[richfitz]

Describe the package

Contents of DESCRIPTION:

Package: rrlite
Title: R bindings to rlite
Version: 0.1.0
Description: R bindings to rlite.  rlite is a "self-contained,
  serverless, zero-configuration, transactional redis-compatible
  database engine. rlite is to Redis what SQLite is to SQL.".
Depends: R (>= 3.1.2)
License: BSD_2_clause + file LICENSE
LazyData: true
Author: Rich FitzJohn
Maintainer: Rich FitzJohn <rich.fitzjohn@gmail.com>
Suggests: testthat
Imports: R6

url: https://github.com/richfitz/rrlite

What data source(s) does it work with (if applicable)?

Key/value data

Who is the target audience?

Package authors, data users. Probably will appeal to more technically inclined people than most ropensci packages but could be an ingredient in other ropensci packages.

Who has/will contribute to this package?

I am currently the only contributor, but @sckott plans on contributing

Are you willing to follow the rOpenSci policies (link), including transferring your repo to the rOpenSci GitHub organization account? [yes/no]

yes

Are you willing to follow the rOpenSci packaging guidelines? If you disagree with any, explain.

yes

[richfitz]

Note: I'm putting this package up way to early because it has lots of faults (it's very embryonic). That way we can work out how we can identify and address the faults as part of this process. In particular:

• there is no documentation
• the README file is not autogenerated
• the travis build is failing
• there is no vignette
• no test coverage has been reported, and is inadequate
• there are 3rd party sources that are not correctly attributed in DESCRIPTION (so would fail to get through with CRAN).

Probably many others too.

[karthik]

These might be meta questions but here are some thoughts:

1. We should perhaps defer on accepting packages in early development? Until it meets a certain standard, we wouldn't accept into our account. This does not mean that a package must be mature in functionality, but as long as it does a few things well, and meets our standards, we can accept it. So work in progress or early dev might be a no go.
2. @sckott For the [yes/no] we should just use GitHub check boxes for those because they can be ticked off as we proceed and things are cleared up.

[sckott]

wrt early dev - Makes sense, though what about the use case in which the person is willing to maintain the pkg, but needs help (e.g. doesn't know git that well, isn't super confident in R pkd dev) - in that case, do we just help them in their account, then move here at some point?

For the [yes/no] we should just use GitHub check boxes

Right, makes sense

[karthik]

what about the use case in which the person is willing to maintain the pkg, but needs help

I see this decision tree. First someone submits a package via this repo:

1. This looks like good fit but the package is way too early in dev. Please revisit when you are further along
2. This package is in early dev but this fits our priority list so we'll accept and rOpenSci team will help you finish
3. This package is in early dev but we are unable to help. Please post into the wishlist repo as in progress - need help and see if someone will help you get this to a better state before submitting

How does that sound?

[richfitz]

Sounds good.

[sckott]

also sounds good

[richfitz]

OK, so say someone submits a package in this state (it's actually close to being feature complete but that's not really apparent), what do we tell them. The package clearly has a lot of potential but there are rough edges and we're all snowed under. Do we have time to do a quick review and give feedback or do we just say - this looks sketchy, come back later?

[karthik]

@richfitz I think in those situations we could address it on a case by case basis. If one of us (or others from the community that we ask to help) has time for a review, we can use the same issue to provide some feedback and close temporarily while those get resolved.
I think with any package, we will do a quick review anyway (even for a rejection). If it turns out that we are all snowed in that we can't even tell them what is wrong, we could punt to the wishlist repo under some category like Needs review.

I'm now starting to think of this as an journal editorial process. We are the EICs. If we are too busy to decide whether or not to review a ms, we can send off to a subject editor to make that call. I can see someone like Gavin, Noam, etc stepping into that role as necessary. thoughts?

[sckott]

Sure, that sounds good to ask if someone can review - seems like we should ask a few people to make sure they are okay with that.

we probably have to be ultimately responsible for decisions though, even if someone else not on leadership team reviews

[richfitz]

I think that's a great way of getting other people more involved. That also suggests that we have a set of topic tags that people can apply to make it clearer what sort of package they have. The categories on http://ropensci.org/packages/ would make a good starting point (data publication, data access, literature, altmetrics, reproducibility, databases, datavis, geospatial).

[karthik]

I think that's a great way of getting other people more involved. That also suggests that we have a set of topic tags that people can apply to make it clearer what sort of package they have. The categories on http://ropensci.org/packages/ would make a good starting point (data publication, data access, literature, altmetrics, reproducibility, databases, datavis, geospatial).

Awesome 👍 💯

we probably have to be ultimately responsible for decisions though, even if someone else not on leadership team reviews

Yeah, I think even if we ask someone else to review, we make the final decision. So maybe subject editor isn't the perfect analogy, but a set of reviewers we rely on who make recommendations to us.

[richfitz]

I think the other distinction is that this is not meant to be an adversarial process.

Does anyone want to volunteer to review my package? Probably best to signal that by self-assigning? If nobody else wants to I'm happy to do it myself.

[sckott]

@richfitz @karthik put up a new version of readme and contirbuing in onboarding

[karthik]

I suggest that we close this and start over in a new issue. I might have said this on the other one.

[sckott]

sounds good

[richfitz]

Migrated to #6

[jennybc]

@richfitz Did @karthik let you in on his proprietary GIF management system during the unconf? You are attaining new heights.

[richfitz]

I wish - I'd bet my gif stockpile is orders of magnitude smaller than @karthik's

[karthik]

@jennybc This is really proof that Rich really belongs at rOpenSci. I hadn't seen that gif before.
I should have proposed a rapid gif deployment session at the unconf. Next year! Nice work @richfitz

[jennybc]

⭐