Package presentations, groups, schedule and guidelines
13 Mar 2015
Guidelines for the package presentations
- The presentations should last about 15 minutes.
- 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.
- 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.
- 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
and this is the
that was used to generate it, you can also click on the “Raw” button to see
the exact source code.
- This Rmarkdown file should be posted on GitHub in the
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
- 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
- Note that you don’t need to commit the html file to your repository, only
- If you have any questions, about the presentation, please
open an issue on GitHub in
- 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.
- The GitHub workflow for forking a repository, commiting and pushing changes
to it, and creating a pull request is listed at the bottom of
- 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”.