Package presentations, groups, schedule and guidelines

• April 10th:
  • Zach and Judit: tidyr + dplyr + magrittr
  • Mitch and Travis: packrat
  • Miao: ape
• April 17th:
  • Richie and Heather-Rose: shiny
  • Sarah and Leslie: rentrez
  • Emily: treebase
  • Charlotte: raster

Guidelines for the package presentations

1. The presentations should last about 15 minutes.
2. The support for the presentation is flexible. You can use powerpoint or keynote, or something else, but I strongly suggest you use an R presentation. If you prefer, you can do live coding (like I do during class) without relying on a slideshow.
3. The type of presentation is also flexible (lecture style vs. live coding), but I would suggest you make it interactive with people following along by having to type the commands you are presenting.
4. In addition of your presentation (you can use the same file as for your presentation if you choose an R presentation), you need to create an Rmarkdown file that should contain:
   • the general purpose of the package;
   • pieces of code that demonstrate how to use it. In other words, it should look like a vignette for a package. Here is an example for the package lubridate and this is the source code that was used to generate it, you can also click on the “Raw” button to see the exact source code.
5. This Rmarkdown file should be posted on GitHub in the package-presentations repository. (I recommend you fork the repository, prepare the presentation in your own fork, and create a pull request when you would like me to review it).
6. Ideally, you should have a draft of your Rmarkdown file on GitHub at least 3 days before you are scheduled to give the presentation. If you do so, I guarantee that I will provide feedback. If you post your notes less than 3 days before I can’t guarantee that I will provide feedback. The easiest way to let me know that your Rmarkdown file is ready for review is to create a pull request.
   • Note that you don’t need to commit the html file to your repository, only the .Rmd file.
7. If you have any questions, about the presentation, please open an issue on GitHub in the package-presentations repository.
8. Don’t worry too much about the formatting of your notes at this stage. Focus on content first, and we can work together on fixing potential issues that hinders the rendering of your file later.

Resources

1. The GitHub workflow for forking a repository, commiting and pushing changes to it, and creating a pull request is listed at the bottom of this page.
2. The RStudio website lists some good references on how to write RMarkdown, in particular look under the “Authoring” tab after reading through the “Quick tour”.