Providing Useful Feedback

Release early, release often. That mantra has served open source really well because it provides an opportunity for developers to get in and provide feedback (and patches) through the lifecycle of a project, and not when something is completely finished and would require huge amounts of efforts to fix problems that could be caught early.

By the same token, release early, release often is a good mechanism for other projects even when they don’t involve code. When working on documentation, marketing materials, artwork, translations, or other non-code materials, it’s a good idea to put something out for comment early. This is not how it’s usually done, and can be a bit painful for people used to working on and submitting a finished or nearly finished product before getting feedback.

Why painful? Because, all too often, soliciting feedback results in as much noise as signal. In addition to thoughtful feedback, contributors often receive snippy comments, off-topic responses, or other non-useful feedback.

Overall, I’ve found many in the open source community to be respectful and good at providing feedback. But it’s the abrasive and negative voices that often stand out and discourage people from being effective contributors — particularly people new to FOSS who aren’t used to working in the open environment. What can be done about this?

• Keep comments relevant: Make sure your feedback is within the scope of the question asked. For example, if asked to provide feedback on a strategy document, it‚Äôs helpful to provide specific comments on the strategy document. It‚Äôs unhelpful to critique the font, choice of hosting service, or whether a strategy document is actually relevant.All too often, a piece of work is put out for public critique and the feedback bears little to no resemblance to the request for comments. For instance, when presented with four options to choose from, it‚Äôs helpful to pick one. It‚Äôs unhelpful to suggest a fifth alternative, especially when you‚Äôre asking others to do the creative.
• Those who do the work should provide the most feedback: Everyone‚Äôs opinion matters, but it matters more if you‚Äôre chipping in. Don‚Äôt be a backseat driver.
• Respect the scope of a request: If someone says ‚ÄúI‚Äôm mocking up a CD cover, what do you think of the layout?‚Äù critiquing the text is a waste of everyone‚Äôs time. Provide feedback where it‚Äôs asked for, not on everything under the Sun.
• Be polite: No matter what your opinion of the work, be objective and polite. Most if not all the work done in most projects is being done by volunteers. While it‚Äôs important to maintain quality standards, it‚Äôs not an excuse to rip into someone‚Äôs ideas or execution. Give tips on improvement, but keep them positive and be aware that someone has made an effort ‚Äî they don‚Äôt deserve to be belittled even if their work isn‚Äôt up to your standards.Giving a thumbs up or thumbs down is great. Saying ‚Äúthat sucks!‚Äù really isn‚Äôt. Yes, the kernel guys and other coders sometimes get pretty pointed in their reviews of patches. It‚Äôs not something to emulate, especially when working with contributors in professions that expect more diplomacy when reviewing work. And yes, I‚Äôm well aware that there‚Äôs plenty of harsh feedback given in other professional environments. However, let‚Äôs leave crushing people‚Äôs souls to the areas where they‚Äôll get paid for it, Mmmkay?
• Be timely: If given a deadline to submit comments, submit them on time. Don‚Äôt expect to put the brakes on a project at the last minute.
• Respect the process: If you‚Äôre asked to vote on something, use the voting tool rather than saying ‚Äú+1‚Ä≥ in the comments. If you‚Äôre asked to submit comments in a specific way, follow the instructions. Processes exist for a reason, so we can all get more work done.

Whether you’re responding to another contributor, a review of your project on a news site, or something else: It never, ever hurts to be polite and respond to the point at hand. The opposite isn’t true.