There's a lot of work that goes in to making software: the code that does the thing itself, unit testing, examples, tutorials, documentation, and support. rOpenSci software is created and maintained both by our staff and by our (awesome) community. In keeping with our aim to build capacity of software users and developers, three interns from our academic home at UC Berkeley are now working with us as well. Our interns are mentored by Carl Boettiger, Scott Chamberlain, and Karthik Ram and they will receive academic credit and/or pay for their work.

The interns

• Katie Rice:
  • Is a third-year undergraduate student doing a major in Environmental Sciences and a minor in Sustainable Design
  • Katie on GitHub
• Diana Ly:
  • Is a third-year undergraduate student doing a major in Mathematics.
  • Diana on GitHub
• Siwei (Steven) Ye:
  • Is a second-year undergraduate student doing a double major in Mathematics and Statistics
  • Steven on GitHub

What they're working on

Katie

README's are the first thing someone reads when landing on a GitHub repository. Thus, it's important that the README has sufficient information to tell the reader what the software is for, who it's meant for, what it does, how to install and how to give feedback.

Most software maintainers do a good job with how to install and how to give feedback (link to issues tab usually), but we often fall short on describing at a high level what the piece of software is about.

This is where Katie comes in! She's been going through rOpenSci repositories on GitHub, improving the high level description of the software and then sending pull requests with changes to the README's.

Check out Katie's GitHub activity for rOpenSci related work.

Diana

Diana is just getting started. She'll be working on documentation and maintenance.

In addition, she'll be working on an R package that will make it easy to make cheatsheets for packages from simple markdown templates – no editing powerpoint or keynote files needed!

Steven

Software unit tests (method to determine whether software components perform as designed) are very important. We have it as policy that packages submitted to our onboarding repository have tests.

In addition, we build and check our software on each change (includes running tests). However, since rOpenSci has been around for a while, there are still some packages that don't have tests, or enough of them. In addition, when you have tests, you can calculate test coverage using, for example with Codecov – a good way to target what tests to write.

Lastly, it's ideal to signal to potential users that you have continuous integration and test coverage through badges, like this one:

This is where Steven comes in! When a package has tests already, he adds integration for Codecov and a badge for it (like the one above) when it's missing. When packages don't have tests, he writes them, including integrating Codecov.

Check out Steven's GitHub activity for rOpenSci related work.

Want to be an rOpenSci intern?

We'll be looking for new interns from time to time. Contact us at [email protected] with any questions.