Table of Contents
One of my favorite parts of R is the community, so I was excited for this year’s Chicago R Collaborative (rebranded from last year’s Chicago R Unconference). I was disappointed that the in-person event scheduled for March had to be canceled, but fortunately the amazing organizers (Angela Li, Emily Riederer, Sydney Purdue, Will Bonnell) were able to quickly pivot to hosting a virtual event last April.
As a mentor for the event, my main goal was to empower R users to become R developers by contributing to open source R projects. I did this via live tutorials demonstrating how to use Git and GitHub, and mentoring contributions to my R package workflowr.
Collaborating with Git and GitHub
A big hurdle for new contributors is learning the technical and social skills to contribute via Git and GitHub. To help with this, I teamed up with Mauro Lepore to do a live demonstration of contributing to an open source project on GitHub. Mauro created a new Git repository, I made a contribution, and he merged my Pull Request. We didn’t record the actual demo so that attendees wouldn’t be self-conscious about asking questions. However, you can watch the practice demo we recorded prior to the event:
After our demo, we had the attendees create their own Pull Requests to this new repository. They submitted R-related tips and tricks. Check out the repository rcollab-git to read their advice. We had 4 attendees successfully submit a Pull Request: Jim Gruman, Eric Nantz, Anna Vasylytsya, and Stefany Samp.
If you’re interested in practicing submitting a Pull Request on GitHub, check out the tutorial I co-authored, A Quick Introduction to Version Control with Git and GitHub. It explains how to submit a Pull Request to the accompanying repository git-for-science.
The second live demo I did was an impromptu idea from Anna Vasylytsya. James Lamb had submitted a Pull Request to my workflowr package, and Anna suggested that I do the code review live so that others could see what this process was like. This was a great learning experience, especially for me!
I reviewed the Pull Request and submitted a GitHub review. I explained that one of the reasons I liked using the GitHub review instead of leaving individual comments was so that the person that submitted the Pull Request would receive one notification instead of individual notifications for each comment (I’ve been on the other end of this, and it can be demoralizing, because the reviewer often starts with the requested changes, and doesn’t add the positive feedback until the end). James added his strategy for leaving reviews, which I thought was a great summary of a social practice that I had adopted but didn’t realize: If you are responsible for the all of the code that the Pull Request affects, you should leave a review to approve or request changes. On the other hand, if you just want to lend your expertise on one aspect of the Pull Request, leave single comments without giving a review.
I also learned more from James about the GitHub feature to suggest changes on a Pull Request. I knew that GitHub had made it possible to suggest edits directly in the source code, but I didn’t realize that the submitter of the Pull Request can accept and convert the suggested edit into a commit without having to leave the GitHub user interface. Very slick.
After having done these two live demos, I realized too late that some aspects of my GitHub user interface may have looked different than the standard because I have the browser extension refined-github installed. In retrospect I should have disabled it for the demos to remove any unnecessary distractions. However, on the plus side it did give me the opportunity to share this GitHub tip. If you spend a lot of time working on GitHub, I recommend giving it a try (especially if you use a lot of CI services). The extension is available for Firefox and Chrome.
Contributions to workflowr
I was very happy to have 3 new collaborators contribute to my R package workflowr. Their contributions described below are already available in the latest CRAN release (version 1.6.2).
Anh Tran overhauled workflowr’s RStudio project template (workflowr Issue #193). The existing version I had created was very minimal, and only exposed a few of the arguments to wflow_start(). Anh created a wrapper function to handle additional arguments passed from RStudio and updated the user interface (PR #200). Furthermore, he created unit tests for the new wrapper function! (PR #205)
Sydney Purdue added some extra error handling to wflow_start() to fail early when the input argument overwrite is used incorrectly (workflowr Issue #194). And she wrote her first unit test! (PR #202)
James Lamb updated the HTTP calls to the GitHub API in wflow_use_github() to be more resilient to transient network issues by using httr::RETRY(), which automatically retries HTTP calls more than once (PR #199, PR #201).
Links to other chircollab 2020 projects and posts
Projects:
kableExtra cookbook - Sharla Gelfand, Brooke Anderson, and Jim Gruman
Collaborative introduction slides converted to xaringan - Eric Nantz and Angela Li
httr::RETRY()- James Lamb, Anna Vasylytsya, Adam Austin, and Tomas Okaldatos - Mauro Lepore and Jonathan Keane
Blog posts:
Tweets: #chircollab