pre-submission inquiry for shinyGEO

[jasdumas]

Hi there,

I'm reaching out to see if my R package / Shiny app is appropriate for submission to rOpenSci. I'm one of the co-developers and asking on be half of my other co-developers and the package maintainer, @gdancik. Our questions and concerns are first is that shinyGEO will need to be updated fairly regularly so users have up-to-date access to the gene expression datasets that are available on GEO, which the package maintainer plans to provide those updates and secondly that potential users will need to have the web app link available alongside the listed R package. Are these concerns feasible?

Here is a description of shinyGEO:

shinyGEO is a web-based tool that allows a user to download the expression and sample data from a Gene Expression Omnibus dataset, select a gene of interest, and perform a survival or differential expression analysis using the available data. For both analyses, shinyGEO produces publication-ready graphics and generates R code ensuring that all analyses are reproducible.

We have it hosted at http://bioinformatics.easternct.edu/shinyGEO/ Here is also our recently published paper in the Bioinformatics Journal: http://bioinformatics.oxfordjournals.org/content/early/2016/08/20/bioinformatics.btw519

Thanks for the feedback!

[noamross]

Thanks for the inquiry, @jasdumas and @gdancik! shinyGEO looks like a great tool. It fits squarely in rOpenSci's wheelhouse in terms of providing access to scientific data an enabling reproducible workflows. (I really like the code generation!)

In its current state, shinyGEO doesn't quite fit into our system, but it could with the following changes:

• Refactor as an R package. We are only set up to accept and maintain software that's bundled as installable packages, but we have several such packages that include or are primarily shiny apps. In general, such packages install like normal R packages and the shiny app is launched locally with a simple function call (like runShinyGEO()). This shouldn't preclude you continuing to host the app on the web, as well.
• Include a test suite. We expect all our packages to have good unit test coverage and be tested via a continuous integration service like Travis-CI.
• Address the maintenance issue. Lots of our packages wrap web APIs and we certainly expect them to have to be maintained and updated as those APIs change. However, if data updates are frequent and relatively standard, it may make more sense to make data updates a user-side function in the package. I notice that the data in series/ and platforms/ are updated via scripts. Perhaps in the package a function like update_GEOdata() or even a button in the app could perform this function so that users can update the lists of GEO datasets directly, rather than relying on package maintainers?

(@sckott may jump in with some other thoughts.)

If you're interested in pursuing these changes, we'd be glad to have shinyGEO in our package suite. We can provide some support and guidance along the way, as well; our Slack room is a good place to ask questions about package development.

[gdancik]

Hi Noam,

Thanks for your quick reply and suggestions for how we can get shinyGEO to fit into rOpenSci. These are all great suggestions and will improve our package. I especially like the idea of an _updateGEOdata() so users can update directly. Jasmine and I will talk more and let you know if we have any questions.

Thanks!

• Garrett

On Sun, Sep 11, 2016 at 9:09 PM, Noam Ross notifications@github.com wrote:

Thanks for the inquiry, @jasdumas https://github.com/jasdumas and @gdancik https://github.com/gdancik! shinyGEO looks like a great tool. It fits squarely in rOpenSci's wheelhouse in terms of providing access to scientific data an enabling reproducible workflows. (I really like the code generation!)

In its current state, shinyGEO doesn't quite fit into our system, but it could with the following changes:

• Refactor as an R package. We are only set up to accept and maintain software that's bundled as installable packages, but we have several such packages that include or are primarily shiny apps. In general, such packages install like normal R packages and the shiny app is launched locally with a simple function call (like runShinyGEO()). This shouldn't preclude you continuing to host the app on the web, as well.
• Include a test suite. We expect all our packages to have good unit test coverage and be tested via a continuous integration service like Travis-CI.
• Address the maintenance issue. Lots of our packages wrap web APIs and we certainly expect them to have to be maintained and updated as those APIs change. However, if data updates are frequent and relatively standard, it may make more sense to make data updates a user-side function in the package. I notice that the data in series/ and platforms/ are updated via scripts. Perhaps in the package a function like update_GEOdata() or even a button in the app could perform this function so that users can update the lists of GEO datasets directly, rather than relying on package maintainers?

(@sckott https://github.com/sckott may jump in with some other thoughts.)

If you're interested in pursuing these changes, we'd be glad to have shinyGEO in our package suite. We can provide some support and guidance along the way, as well; our Slack room is a good place to ask questions about package development.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/onboarding/issues/74#issuecomment-246217876, or mute the thread https://github.com/notifications/unsubscribe-auth/AK2T21AtjXc5m0SJL3tRyyz04muX2qedks5qpKZkgaJpZM4J6HJY .