Today I wrote this post describing my difficulties in getting started with Ember.js, a quite well known open source project.
Normally, when I find small issues in an existing project, I try to help by sending a PR–some things are just faster to describe by coding them than by writing a bug report. But the case here was something that requires way more involvement than me filing a trivial bug. I tried to offer constructive feedback, and do that in as much detail as possible so that the authors could understand what happens in somebody else’s mind when they approach their project. From a usability and information design perspective, this is great information to have!
Shortly after, Tom Dale contacted me and thanked me for the feedback, and said they were working on improving all these aspects. That was great.
What is not great is when other people insta-ask you to send PRs or file bugs:
@supersole as the core would say, those are considered bug reports so feel free to file them on github! it really helps the writers as well
— Ricardo Mendes (@locks) February 18, 2015
Look, I already gave you A FULL LIST OF BUGS in excruciating detail. At this stage my involvement with the project is timid and almost insignificant, but I cared enough to give you good actionable feedback instead of just declaring that your project sucks in a ranty tweet.
The way you handle these initial interactions is crucial as to whether someone decides to stay and get more engaged in your community, or run away from you as fast as they can.
A response like Tom’s is good. He recognises I have more things to do, but offers to listen to me if I have feedback after they fix these issues. I can’t be sure I will work more with Ember in the future, but now I might check it out from time to time. The potential is still there! Everyone’s happy.
An entitled response that doesn’t acknowledge the time I’ve already invested and demands even more time from me is definitely bad. Don’t do this. Ever. What you should do instead is act on my feedback. Go through it and file bugs for the issues I mentioned. Give me the bug numbers and I might even subscribe to them to stay in the loop. I might even offer more feedback! You might even need more input! Everyone wins!
This is the same approach I use when someone who might not necessarily be acquainted with Bugzilla or Firefox tells me they have an issue with Firefox. I don’t just straight tell them to “FILE A BUG… OR ELSE” (unless they’re my friends in which case, yes, go file a bug!).
What I do is try to lead by example: I gather as much information from them as I can, then file the bug, and send them the bug URL. Sometimes this also involves building a test case, or extracting a reduced test case from their own failing code. This is work, but it is work that pays off.
These reporters have gone off to build more tests and even file bugs by themselves later on, not only because they saw which steps to follow, but also because they felt respected and valued from the beginning.
So next time someone gives you feedback… think twice before answering with a “PATCHES WELCOME” sort of answer—you might be scaring contributors away!