Meetings

2021-02-01 - UseR proposal

Organisation

• Small groups + Breakout rooms: 30 attendees for 3 instructors

Questions

• For the title, we can certainly use "Rmd First" like your blog post instead of mine if you would prefer! In the past, I've emphasized that "your end result doesn't have to be a package", so "Rmd First" is perhaps even more clear that our goal is definitely a package here! Please use whichever you prefer
  • How to build a package following "Rmd First" method
• For the learning goals, what are you thinking for "know how to share their work with the community"? Do you think we should cover GitHub? CRAN? tar files?
  • Thinking about "git + GitHub + pkgdown": know it exists
  • usethis::use_git() + commit + usethis::use_github_actions("pkgdown") + push
• Do you have any tentative vision for how we will break topics across 3 hours? I suspect we could perhaps do it in two hours but, then again, I never leave enough time for anything (😆). As I think about how to break out the content, I suppose we could do:
  • Breaking Rmd into functions / Migrating modular components to package structure / Re-doing process with fusen
  • Overview of process (not sure what exercises would be then - perhaps working in groups to understand a sample Rmd and deciding what parts are specific to one analysis vs what parts are generally applicable?) / Implementation / Re-doing process with fusen
  • Something else
• Should we have function writing be an explicit prerequisite? I don't know if there is a risk that if we try to cover everything from writing one's first functions to writing one's first packages all at once, we might move too fast and confuse learners
  • It is more open if we do not force to be able to "write" functions before coming
• Do we need to require microphones? Hopefully most everyone has them, but people could also ask questions via Slack, etc. so I would hate for this to completely be a barrier for someone
  • This is to make understand attendees that are supposed to participate but this will be a safe environment
• Wow! ThinkR's tutorial platform looks fantastic
  • Test it : https://cruz.thinkr.fr (Better with Chrome)
    • User: thomas_anderson-sc_demo
    • password: YVBeFyBSowdnDpz4
• How to breakout ?
  • Random, but the same random for each sub-groups in each exercises parts
• Time
  • 7:00-10:00 (Emily) => 14:00-17:00 (Seb)
  • 8:00-11
  • 9:12

Content

Find a dataset on which to do some filters, graphs A package for data analysis for internal use Focus on package build, and not on functions creation

• Writing functions
• Subjective (perhaps from tidyverse?) function design principles
  • Find correct function names
  • Name functions with lowercase
• Writing roxygen2 documentation
• Writing tests for functions with testthat
  • You already checked, why don't turn into a test ?
• Managing function dependencies (in roxygen and DESCRIPTION)
  • attachment::att_amend_desc()
• Advanced function concepts (default arguments, ellipsis)
• Problems / nuances when turning tidyverse code into function (.data pronoun)
• R Markdown parameters (as intermediary step before package)
  • Parametrized Rmd
• source()ing separate function files into a project (as intermediary step before package)
• R projects (as intermediary stage to package)
• R-specific data formats (Rdata, Rds)
  • system.file() only ?
  • Preserve raw-data
  • devtools::load_all()
• [?] File structure of an R package
• usethis package (does this make sense if we teach fusen?)
• Making documentation websites with pkgdown
  • Present but not explain
  • A goal of the tutorial
• "Advanced" package components like templates, add-ins
• fusen package
• Sharing a package on CRAN
• Sharing a package as a tar file
  • remotes::install_local("")
• Sharing a package on GitHub / GitLab
• Hosting a package website on GitHub
• Automating testing with GitHub Actions
  • Explain what is CI if time allows ?