Just a clarification, is the idea to continually go back to 1 BoF topic for each breakfast/lunch in the conference? On one hand, I'm immediately drawn to the Finance BoF session, and could see the value in attending that session each time we have a meal to continually work on a mini-project with people. On the other hand, the Software and Package Development session that has been suggested would also be interesting, and I might want to bounce between it and Finance.
Just wanted to understand more about how RStudio sees these sessions playing out.
Maybe something about best practices for maintaining R versions/packages at institutional levels? How many versions of R do you keep? How do you manage packages (bioconductor, CRAN, github, local) - balancing the need for reproducibility (paper came back from reviewers but R/packages have changed) with consistency across projects/space (+ some packages are hard to install). Or best practices for shiny apps/R Connect. How long do you guarantee they will be there/work without updating?
Could the above topic be bundled with 'challenges in reproducible workflows' --- maybe a snazzier title would be "Good Enough Practices for Reproducibility?" (an homage to the nice, recent paper by Wilson, Bryan et al in PLOS: Computational Biology.
I would bet that there are a lot of R users who are trying to grow adoption at their workplaces and the project of building systems for collaborative data analysis means not just spreading the R gospel, but also adoption of data and version control systems that facilitate collaboration.
I am also in government, so the reproducible workflow discussion speaks to me, but I feel like the fully open-source workflow is better documented than the challenges of building good R systems that work with internal data.
A session for R in environmental research (geophysical, DEM, hydrological, biological, etc.) could be useful for learning of existing tools and packages and their strengths and limitations.