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 (https://github.com/ropensci/reproducibility-guide) so it might be worth combining forces.
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
- Identify mapping requirements of
- Consolidate map data formats that R users typically work with.
- 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.
- Identify mapping requirements of
Interoperabilty of data formats from rOpenSci Packages
See discussion in Issue #20
- 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
bibentryclass 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.).
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
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.
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)
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.
mockersomething like https://github.com/ropensci/mocker). But we could also think about web caching. @mbjones brought up some good things to think about here https://github.com/ropensci/hackathon/issues/21#issuecomment-38932220