As October rolls around once more, the term Hacktoberfest might pop across your feeds; an effort aiming to encourage people to contribute to open-source software, particularly if they’re new to that. In this post I’ll describe what I’m offering towards that goal.

Hacktoberfest has been running since (I think) 2017 and I’ve participated in at least one year – previously contributors who had the requisite 4 PRs merged received a free t-shirt, but I suspect that program became overly costly.

The site describes this as “DigitalOcean’s annual event that encourages people to contribute to open source” and while one could be cynical (as I usually am) about a corporate-sponsored “hack” event I have instead decided to take the opportunity to be encouraging, and help raise the abilities of more developers. A rising tide lifts all boats.

Even I started somewhere…

I’ve been sending code suggestions in the form of pull requests to repositories I don’t own for very nearly 10 years now – it seems I created my GitHub account on Nov 1, 2014.

I created my GitHub account and made my first pull request on Nov 1, 2014

I made my first pull request in the now archived repository for the {twitteR} package to fix a single-letter typo in some code, presumably because I noticed it was broken when using it

Changing “errrors” to “errors”

and in which I apologised just in case I was fixing something that wasn’t broken (in hindsight, it clearly was, but this was my first ever pull request, so, nerves, I guess).

Judging by the default pull request title “Update ” I used the web interface to achieve this rather than actually pulling a local copy of the codebase – I now know that titles are a useful way to understand what changes are being made, especially when looking through a list of pull requests or issues to see if what you’ve found is already being addressed somewhere. “This is broken”, “doesn’t work”, “fixed things” are all unhelpful titles when it comes to browsing a list of these and trying to figure out if the JSON parsing throwing an unexpected error is a ‘known bug’. You gotta start somewhere, though.

Since then I’ve created another 271 pull requests (according to GitHub) to various repositories – some my own (82) but most not. It’s all too easy to forget how familiar I’ve become with that workflow.

At RWeekly we encourage users to submit new blog posts to us (particularly those that we aren’t otherwise likely to capture via our RSS feed fetches) via pull requests, and we try to make that as smooth as possible, but I would bet there’s a reasonable number of readers out there who don’t feel comfortable with the pull request process to do that.

There’s no shortage of material on the web explaining how to work with pull requests in R either at the command line or in RStudio

• https://r-bio.github.io/intro-git-rstudio/
• https://rfortherestofus.com/2021/02/how-to-use-git-github-with-r/
• https://www.r-bloggers.com/2019/01/a-newbies-guide-to-making-a-pull-request-for-an-r-package/
• https://r-pkgs.org/software-development-practices.html#git-pullreq

but that’s theory – how does a new user practice making a pull request?

Sure, you could create a toy repository, make your own pull request to that and merge it yourself – and I recommend you do, it’s great practice – but will that make you sufficiently comfortable to make a request to someone else’s codebase?

If not, I’m here for you…

Introducing {safespace} which is a “broken” repository full of things that need fixing, with zero consequences if you accidentally break something while learning. The idea of this repository is to have somewhere a very new user can submit a real pull request, have it reviewed (with compassion but aiming to help you improve), and merged. As a bonus, it’s tagged with the hacktoberfest topic, so if you do get a pull request merged it counts towards your contributions; if you have 4 pull requests started and merged during October across participating repositories you get a shiny digital badge!

The repository contains a “real” (but toy) R package that is currently in a broken state – it requires some code changes to make it work. It also has all sorts of things that could be improved; typos, documentation, logic issues, etc… it’s also (hopefully) a good way to learn about building R packages and seeing what needs to be fixed.

My target audience for this repository is people who wish they had somewhere to send a real pull request because they don’t yet feel comfortable participating in open source software. It’s not for people already comfortable who just want to show off that they can make pull requests or code changes; I’ll probably just close any of those if I spot them.

I’ve added some instructions to the README since this audience is, by definition, less familiar with the workflow. If those aren’t clear enough or are plain old wrong, please let me know!

Open a pull request suggesting some code changes, and I’ll provide some feedback on the changes; things you may have overlooked, other ways to achieve the same, or notes on construction. All going well, by the end of October, the repository and package will be in a fully “working” state, passing devtools::check(), and with some reasonable documentation.

If you’re really unsure about the whole ‘contributing code’ thing but can see something that looks broken, you can also create an Issue which is a sort of ‘bug report’ feature on GitHub where you identify something that could be improved without necessarily fixing it. You can make code suggestions in there, but it still needs someone to implement the change.

Lastly, this really only works if some of the people who would benefit from such a learning opportunity find out about it, so boosts and re-shares of this post, the toot announcing it, or the link to the repository itself

https://github.com/jonocarroll/safespace

would be greatly appreciated.

As always, I can be found on Mastodon and the comment section below.

## ─ Session info ───────────────────────────────────────────────────────────────
##  setting  value
##  version  R version 4.3.3 (2024-02-29)
##  os       Pop!_OS 22.04 LTS
##  system   x86_64, linux-gnu
##  ui       X11
##  language (EN)
##  collate  en_AU.UTF-8
##  ctype    en_AU.UTF-8
##  tz       Australia/Adelaide
##  date     2024-10-01
##  pandoc   3.2 @ /usr/lib/rstudio/resources/app/bin/quarto/bin/tools/x86_64/ (via rmarkdown)
## 
## ─ Packages ───────────────────────────────────────────────────────────────────
##  package     * version date (UTC) lib source
##  blogdown      1.19    2024-02-01 [1] CRAN (R 4.3.3)
##  bookdown      0.36    2023-10-16 [1] CRAN (R 4.3.2)
##  bslib         0.8.0   2024-07-29 [1] CRAN (R 4.3.3)
##  cachem        1.1.0   2024-05-16 [1] CRAN (R 4.3.3)
##  callr         3.7.3   2022-11-02 [3] CRAN (R 4.2.2)
##  cli           3.6.1   2023-03-23 [1] CRAN (R 4.3.3)
##  crayon        1.5.2   2022-09-29 [3] CRAN (R 4.2.1)
##  devtools      2.4.5   2022-10-11 [1] CRAN (R 4.3.2)
##  digest        0.6.37  2024-08-19 [1] CRAN (R 4.3.3)
##  ellipsis      0.3.2   2021-04-29 [3] CRAN (R 4.1.1)
##  evaluate      0.24.0  2024-06-10 [1] CRAN (R 4.3.3)
##  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.3.3)
##  fs            1.6.4   2024-04-25 [1] CRAN (R 4.3.3)
##  glue          1.7.0   2024-01-09 [1] CRAN (R 4.3.3)
##  htmltools     0.5.8.1 2024-04-04 [1] CRAN (R 4.3.3)
##  htmlwidgets   1.6.2   2023-03-17 [1] CRAN (R 4.3.2)
##  httpuv        1.6.12  2023-10-23 [1] CRAN (R 4.3.2)
##  icecream      0.2.1   2023-09-27 [1] CRAN (R 4.3.2)
##  jquerylib     0.1.4   2021-04-26 [1] CRAN (R 4.3.3)
##  jsonlite      1.8.8   2023-12-04 [1] CRAN (R 4.3.3)
##  knitr         1.48    2024-07-07 [1] CRAN (R 4.3.3)
##  later         1.3.1   2023-05-02 [1] CRAN (R 4.3.2)
##  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.3.3)
##  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.3.3)
##  memoise       2.0.1   2021-11-26 [1] CRAN (R 4.3.3)
##  mime          0.12    2021-09-28 [1] CRAN (R 4.3.3)
##  miniUI        0.1.1.1 2018-05-18 [1] CRAN (R 4.3.2)
##  pkgbuild      1.4.2   2023-06-26 [1] CRAN (R 4.3.2)
##  pkgload       1.3.3   2023-09-22 [1] CRAN (R 4.3.2)
##  prettyunits   1.2.0   2023-09-24 [3] CRAN (R 4.3.1)
##  processx      3.8.3   2023-12-10 [3] CRAN (R 4.3.2)
##  profvis       0.3.8   2023-05-02 [1] CRAN (R 4.3.2)
##  promises      1.2.1   2023-08-10 [1] CRAN (R 4.3.2)
##  ps            1.7.6   2024-01-18 [3] CRAN (R 4.3.2)
##  purrr         1.0.2   2023-08-10 [3] CRAN (R 4.3.1)
##  R6            2.5.1   2021-08-19 [1] CRAN (R 4.3.3)
##  Rcpp          1.0.11  2023-07-06 [1] CRAN (R 4.3.2)
##  remotes       2.4.2.1 2023-07-18 [1] CRAN (R 4.3.2)
##  rlang         1.1.4   2024-06-04 [1] CRAN (R 4.3.3)
##  rmarkdown     2.28    2024-08-17 [1] CRAN (R 4.3.3)
##  rstudioapi    0.15.0  2023-07-07 [3] CRAN (R 4.3.1)
##  sass          0.4.9   2024-03-15 [1] CRAN (R 4.3.3)
##  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.3.2)
##  shiny         1.7.5.1 2023-10-14 [1] CRAN (R 4.3.2)
##  stringi       1.8.4   2024-05-06 [1] CRAN (R 4.3.3)
##  stringr       1.5.1   2023-11-14 [1] CRAN (R 4.3.3)
##  urlchecker    1.0.1   2021-11-30 [1] CRAN (R 4.3.2)
##  usethis       3.0.0   2024-07-29 [1] CRAN (R 4.3.3)
##  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.3.3)
##  xfun          0.47    2024-08-17 [1] CRAN (R 4.3.3)
##  xtable        1.8-4   2019-04-21 [1] CRAN (R 4.3.2)
##  yaml          2.3.10  2024-07-26 [1] CRAN (R 4.3.3)
## 
##  [1] /home/jono/R/x86_64-pc-linux-gnu-library/4.3
##  [2] /usr/local/lib/R/site-library
##  [3] /usr/lib/R/site-library
##  [4] /usr/lib/R/library
## 
## ──────────────────────────────────────────────────────────────────────────────