Scott Chamberlain edited this page Mar 30, 2014 · 17 revisions

Proposed projects

  • The rOpenSci cookbook [repo]
    Generating documentation in book form. More on the original issue. Chat with Martin Fenner or join the docs room to participate. Note: This project is closely related to the reproducibility guide ( so it might be worth combining forces.

  • Native R kernel for IPython [repo]
    This R package allows interaction with the R kernel without requiring R magic. Chat with Thomas Kluyver, or join the hackathon room in chat.

  • rMaps: Interactive Maps from R [repo] rMaps is an R package to create, customize and publish interactive maps from R. The goal of this project (at least in my mind!) during the hackathon would be four-fold

    1. Identify mapping requirements of rOpenSci packages.
    2. Consolidate map data formats that R users typically work with.
    3. Identify javascript mapping libraries that provide needed mapping functionality.
    4. Write simple functions in rMaps that allow users to create and customize interactive maps using a syntax interface that is not far from how they would do static maps.
  • Interoperabilty of data formats from rOpenSci Packages

    See discussion in Issue #20

    Possible goals

    • Identify standard data schema for serializing relevant data that can be interpreted between packages. (Metadata standards such as [EML], [OAI-ORE], common relevant ontologies [Dublin Core], [Darwin Core], ...)
    • Identify ropensci packages accessing related data but returning that data in different formats (literature packages, spocc-associated packages, etc)
    • Create worked example of code to support automated data integration through serializing data sources into a common standard and then performing the integration step based on the standard.
    • A simple first example could be citations to data. Almost all packages access things a researcher might want to cite, and standard, portable schema for citations are common (e.g. R's native bibentry class can already read and write into the decades-old standard bibtex; we also have support for reading this information in more modern standards such as crossref and datacite schema, and Dublin core / OAI-PMH).
  • API Status Dashboard

    See discussion in issue #3

    We work with a lot of web APIs in ropensci. It would be great for us, and for our users, to have a one stop website to see status of all APIs we work with. There are a lot of options here in terms of frameworks (e.g., Dashing), and languages (dogfood our code in R, or use Ruby, JS, etc.).

  • Sustainable Software

    This project is discussed at some length in issue 19. The discussion highlights larger issues with R's core design and CRAN's policies regarding package dependencies. While we won't seek to solve the problem for all of CRAN, this group could outline and implement best practices in our own software ecosystem of ropensci packages. This is particularly important for us as many of our packages depend on each-other (and on a core set of other packages like httr, XML, etc), as well as on the interfaces provided from the RESTful API's they access. Changes in either of these dependencies, as well as any changes we introduce to the packages themselves, could thus easily ripple through our ecosystem, breaking older tutorials, user code, or even our other packages.

    • What steps can we take to minimize the chance of our package ceasing to operate as before (ideas from @hadley particularly on the REST end). This is discussed in issue #23
    • What mechanisms can we put in place to detect and minimize changes in our own package API/function namespace that might break downstream compatibility? What is our procedure when such changes are necessary? (e.g. semantic versioning indicates that a change to the major number of the package breaks backwards compatibility; meanwhile some CRAN packages instead set the precedent of releasing a new package, e.g. reshape vs reshape2. Is it sufficient to do the latter only when we have reverse dependencies (e.g. dismissing non-CRAN packages / user code)?
    • Do we ever want to move to a versioned release of an ropensci suite? (see @jeroenooms proposal)
  • Caching data

    See discussion in issue #21

    I am not sure if we can solve this issue in two days, but it would be great to at least talk about this issue and see if we can't come up with some consensus on what some good approaches would be to the various use cases for data caching. There are already a few options on the R side (e.g. knitr caching, or mocker something like But we could also think about web caching. @mbjones brought up some good things to think about here