“Patches Welcome”

As a phrase, this is often more of a conversation killer rather than encouragement for collaboration.

The delivery method of this popular phrase is paramount, and the audience needs to be genuinely considered when we say “patches welcome” to those that come forth with recommendations for our products.

Let’s use an example

Let’s say I have a popular plugin, and a user (not a developer) comes to me with a feature request. I may have feelings about their request – I may “know” that that request wouldn’t work, and tell them so. When the user comes back and says, “well why can’t it do this [miraculous thing] by default?” Our too frequent response of “patches welcome” isn’t very welcoming.

This phrase is easy to say when someone encounters us with a difficult problem to solve. I’d argue that sometimes we use this phrase in areas where the feedback is much inline with where we see our own weaknesses in our product. But that’s unfortunate.

Creating avenues for feedback and collaboration takes effort

It’s really hard to provide an avenue for simple and frictionless feedback. It takes work. I certainly know that I crave feedback on my writing and methods of delivering content, but creating ways to receive good feedback takes considerable effort in itself. I’d need to have non-intrusive but noticeable forms and surveys to receive it. I’d have to analyze and filter the feedback. Then I’d have to respond. And finally I may implement some of the changes.

But this process is important, and one I intend to do better at than my basically invisible contact form. Especially with products and services that we sell. Any feedback we can get from real users is extremely valuable, positive or negative (but probably even more so when negative).

One of the primary things I hear from product makers is they don’t know who (as in what type of person) is using their product and they often don’t know how they are using it. Those that bring feedback help us solve these mysteries.

What is a patch, even?

“Patches welcome” delivered to someone that isn’t a developer is in itself a barrier. Many users of our plugins, that are perfectly capable of providing outstanding feedback, probably don’t even know what a patch is, much less how to make one.

When we receive feedback (good or bad), our first and immediate response should be a big, “Thank you!” Second, we should consider our audience.

Ain’t nobody got time for that

Even if the person offering feedback is a developer, they may be doing as much as they can time-wise just in offering the initial feedback.

I often fall in this camp. I run across boatloads of products and services in the WordPress ecosystem. However, I simply cannot go out of my way to offer more than, “hey have you considered this?” type of feedback to most of them. I just don’t have the time.

That makes it yet again extremely important to make the process for offering feedback simple.

Too big for my code

I know I often struggle with this. With big pieces of software – say like WordPress core itself, Jetpack, or any eCommerce plugin – the thought of changing those codebases scares me.

I often have little idea for what the implications for my changes may be elsewhere, and it sometimes intimidates me from participating in the process of writing code for these platforms at all.

Perhaps something that could help in such situations is a “guided tour” of sorts for new contributors to get to know the codebase, its organization, and how things are connected. And this wouldn’t only be valuable for receiving better feedback and more collaboration – it would be excellent as a developer that’s just building something on these platforms.

Product creators usually have a great grasp of their own code organization, but every time I dive into a new codebase it takes me considerable time to grasp the structure of it, even if it’s a similar application to something I’ve used before. That’s happened to me many times with eCommerce plugins.

Various avenues for feedback

“Patches welcome” insinuates a lack of interest in any form of feedback but code. But that is a huge mistake. Feedback can be valuable at any stage. Before code is written, errors and problems need to be discovered and verified. Potential solutions need to be discussed and thought about in a grander scheme of the overall product. Perhaps then even a timeline or plan of action needs to be created for implementing a change. And finally, code needs to be written.

So when we make ourselves open, saying “hey, the code is open in the repo” isn’t enough. Certainly, tools like Github help collaboration tremendously, but not just for the code hosting. Github’s issue tracking and conversations and starring, etc, are extremely valuable for encouraging a complete circle of development.

But even Github is too much for some, or too time consuming for others. On our websites, we should have easy to access (just the look and name of Github could be scary to an end user) methods for offering feedback, bug reports, feature requests, and more.

One of my personal things I like to do is just get a product maker on Skype and tell them how I’m using their product and things I notice. It’s not the most efficient method, but it’s a real in-person conversation, and I’ve yet to meet someone that didn’t value my input. So maybe offer your Skype username to your users so they can contact you directly after offering feedback.

“Feedback Welcome”

So, next time you have a user or fellow developer come to you with a feature request, a bug report, unexpected behavior, or just a general complaint; consider avoiding “patches welcome” and instead say, “Thanks, go here!” and point them to a dedicated place where you highlight the various ways for your community members to offer feedback – code or not code.

Keep the barriers to entry for those locations low. Very low. And always remember to say “thanks”, because usually that’s all it will take for them to continue being a great contributor to your community.