class: center, middle, inverse, title-slide # My Journey from Package User to Package Developer… ## …and how to invite more users to take this journey ### Hugo Gruson ###
grusonh
bisaloo ### 2021-04-22 --- class: center, middle, inverse <style type="text/css"> li, p { font-size: 1.7rem; line-height: 150%; } .footnote { font-size: 1rem; } </style> # My story ### How I got started and fell in love with package development --- ## My first contribution to an R package .pull-left[ <img src="figs/workflow.png" width="100%" style="display: block; margin: auto;" /> ] .pull-right[ ### pavo A cohesive framework for parsing, analyzing and organizing colour from spectral data. ] --- ## My first contribution to an R package 0. Always on the look out for new features, avid reader of `NEWS` files -- 0. Browsed the GitHub repo (https://github.com/rmaia/pavo) 0. Noticed an open issue I knew how to solve -- 0. Contacted the devs 😱 and offered a PR ??? - didn't know the etiquette - was afraid they would be offended I told them their package is not perfect -- Continued contributing and eventually became an official maintainer -- Felt empowered and started working on other R packages --- class: center, middle ## How to facilitate this transition? ## How to make sure projects are not simply open-source but community projects? --- ## Many users think their feedback would not be valued <img src="figs/anti_feedback.png" title="Twitter conversation with person 1 saying "Does anyone else refresh the page every 5 min after posting an issue on Github to see if the developer has answered, or am the only one that anxious?" and person 2 answering "Never because I know they don't actually want to deal with that shit. I feel lucky to ever get a reply."" alt="Twitter conversation with person 1 saying "Does anyone else refresh the page every 5 min after posting an issue on Github to see if the developer has answered, or am the only one that anxious?" and person 2 answering "Never because I know they don't actually want to deal with that shit. I feel lucky to ever get a reply."" width="65%" style="display: block; margin: auto;" /> ??? Twitter conversation: - ask how they feel after submitting an issue on GitHub usual pattern: something is broken/unclear -> give up and move on we want: something is broken/unclear -> report the issue This is what I want to address --- class: center, middle, inverse # How to foster a community around your package ??? Tips to make it less scary, more rewarding to give feedback / contribute Based on my experience -> very subjective. Interested in discussing this after. --- layout:true ## Have confidence in your project and expect contribution --- -- <img src="figs/lluis_package_interest.png" title="Screenshot from a GitHub comment at https://github.com/ropensci-org/community-calls/issues/21#issuecomment-767504258. Text reads: "Just an anecdote of my most active repository, in terms of issues. This repository is a 5 years old program we wrote for an assignment of my M.Sc. We didn't expect to be used outside the class, but as it was left on Github some people found it and used it. We realized people were using it when some people starred the repo, then some time later some users reported troubles they had with it."" alt="Screenshot from a GitHub comment at https://github.com/ropensci-org/community-calls/issues/21#issuecomment-767504258. Text reads: "Just an anecdote of my most active repository, in terms of issues. This repository is a 5 years old program we wrote for an assignment of my M.Sc. We didn't expect to be used outside the class, but as it was left on Github some people found it and used it. We realized people were using it when some people starred the repo, then some time later some users reported troubles they had with it."" width="100%" style="display: block; margin: auto;" /> ??? https://github.com/ropensci-org/community-calls/issues/21#issuecomment-767504258 --- <img src="figs/package_interest.png" title="Screenshot from a GitHub comment closing a pull request with the following text: "Hi! Thanks for your suggestions. My apologies for responding so (!) late. For a very long time I didn't check pull requests, since I didn't really expect people to be interested enough in this project to want to contribute :) In the meantime, many of your suggestions or variations thereof have been already integrated in the code. The internal structure of the package has changed so much, that I will not merge this pull request. Best, [Maintainer name]"" alt="Screenshot from a GitHub comment closing a pull request with the following text: "Hi! Thanks for your suggestions. My apologies for responding so (!) late. For a very long time I didn't check pull requests, since I didn't really expect people to be interested enough in this project to want to contribute :) In the meantime, many of your suggestions or variations thereof have been already integrated in the code. The internal structure of the package has changed so much, that I will not merge this pull request. Best, [Maintainer name]"" width="75%" style="display: block; margin: auto;" /> ??? Otherwise, we are running the risk of missing out on contributions By the time they saw my PR, it was out of date --- layout: false ## Show that you are available and want to communicate -- - If possible, allow to contact you through various platforms -- - Share the recent changes (`NEWS.md`) of your package on these platforms -- - Open issues with unresolved questions (possibly tag as `help-wanted`) ??? on some projects, noticed most feedback comes via email or twitter engagement, feeling of a community --- layout: true ## Don't let contributors work for nothing / feel ignored --- - Acknowledge feedback: - with a quick (even short) answer - with a shout-out / addition to contributors later --- - Acknowledge feedback - Always push your recent work in the public repo (don't keep local branches) --- - Acknowledge feedback - Always push your recent work in the public repo (don't keep local branches) - Share upcoming development (roadmap) of your package -- <img src="figs/scott_notes.png" title="Screenshot from Scott Chamberlain sharing notes from a (private) staff meeting on the public repository at https://github.com/ropensci/biweekly/issues/32" alt="Screenshot from Scott Chamberlain sharing notes from a (private) staff meeting on the public repository at https://github.com/ropensci/biweekly/issues/32" width="75%" style="display: block; margin: auto;" /> --- - Acknowledge feedback - Always push your recent work in the public repo (don't keep local branches) - Share upcoming development (roadmap) of your package - `usethis::use_release_issue()` <img src="figs/use_release_issue.png" title="Screenshot from `usethis::use_release_issue()` documentation. The sentence `"It also helps watchers of your package stay informed about where you are in the process." is highlighted." alt="Screenshot from `usethis::use_release_issue()` documentation. The sentence `"It also helps watchers of your package stay informed about where you are in the process." is highlighted." width="75%" style="display: block; margin: auto;" /> --- layout:true ## Reduce the workload --- --- - Disable failing tests <img src="figs/failing_ci.png" title="Screenshot of CI failure unrelated to the current pull request throwing off an occasional contributor" alt="Screenshot of CI failure unrelated to the current pull request throwing off an occasional contributor" width="75%" style="display: block; margin: auto;" /> --- - Disable unnecessary bots (e.g. coverage bot) <img src="figs/codecov_bot.png" title="Screenshot from codecov-io bot on a pull request" alt="Screenshot from codecov-io bot on a pull request" width="70%" style="display: block; margin: auto;" /> ??? To be honest, still not sure how to read it today... --- layout:false ## But leave opportunities to learn -- - Avoid using the 'Allow edits from maintainers' feature <img src="https://docs.github.com/assets/images/help/pull_requests/allow-maintainers-to-make-edits-sidebar-checkbox.png" title="Screenshot presenting the "Allow edits from maintainers" feature" alt="Screenshot presenting the "Allow edits from maintainers" feature" width="70%" style="display: block; margin: auto;" /> .footnote[More information on [GitHub blog](https://github.blog/2016-09-07-improving-collaboration-with-forks/) and in [GitHub documentation](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork).] ??? demotivating -> cf carpentries advice "don't grab the keyboard from a learner" empowering --- class: middle, inverse # Summary - Have confidence in your project and expect contribution - Show that you are available and want to communicate - Don't let contributors work for nothing / feel ignored - Reduce the workload - But leave opportunities to learn ??? We're not perfect ourselves and still have a lot to do Over to Steffi