Contributions to the tidyverse, and to open source software in general can be framed as various forms of “feedback.” Giving useful feedback can be hard! That’s one of the reasons that File issues is part of our contributing guide. Hopefully, it’s a mutually-beneficial endeavor — if you’ve found a bug while getting help, we want to know about it so we can improve the software.
For the purposes of this post, let’s suppose you’ve found a bug or there’s a feature you’d like to see added to one of your favourite packages. Being the thoughtful user that you are, you’ve made your way to the appropriate GitHub repo. Before writing anything, you search the existing issues to see if it’s already there, or perhaps you’ve landed yourself in the open issue by way of searching for your error message. The point is: you have an issue, and you’re not alone — someone’s beat you to the punch/blazed a trail ahead of you.
Sometimes you’ll have something to add to the conversation (like adding a reprex if one doesn’t exist, or making an existing reprex more minimal), but that’s not always the case. This is precisely what GitHub Reactions were meant for. To quote from their launch post:
We’re adding Reactions to conversations today to help people express their feelings more simply and effectively.
GitHub has six reaction types, but we’ve bagged them into two categories,
:+1: (thumbs up), and the others.
When we pull the repo, issue, and reaction data together we end up with something that looks like the following figure.
It’s a far cry from a fancy report, but it provides another avenue for easy communication among users and developers.
How do I react?
As long as you have a GitHub account, all you need to do is click-and-pick.
This isn’t a true upvoting system, just a way of saying
+1 without having
to write a comment to that same effect.
What if the issue is closed?
We are not tracking reactions on closed issues.
What about comments?
Comments are great, and they’re not going away. Tracking upvotes is intended to be an at-a-glance indicator. Comments don’t serve this purpose quite so well, as they can be positive, negative, or anything in between.
Does this mean that issues will be dealt with sequentially by popular demand?
Nope. While we want and value your feedback, our development process isn’t a popularity contest — we carefully weigh the severity of the issue, the number of people it affects, our estimate of how much time it will take to fix, and our current development foci to decide what to work on next.
If you go to a GitHub repo to file an issue/request a feature and find an open thread, give it a thumbs up: we are listening!