On “predetermined” outcomes

In open source projects (and democratic governments), leaders present policy proposals for feedback before they’re adopted. This often leads to comments like “why bother? They’ll just do what they’ll want anyway.” Sometimes the comments come before the proposal is adopted, sometimes after. No doubt some people only send proposals through a comment period to go through the motions, but the general case is that they sincerely want feedback to improve the proposal.

It’s important to recognize that a substantially-unmodified proposal doesn’t necessarily mean the feedback was ignored. You’re obliged to listen to the comments in good faith; you’re not obliged to be convinced by them.

Making a proposal isn’t an act of neutrally pulling a possibility from the ether. Of course you’re going to propose something that you’re convinced is the best course of action. But others have different perspectives and will think of things you didn’t consider. And they may not share your view of what’s important or what’s a worthy trade off. You know all of this already.

But when, after the comments, you remain convinced of your proposal, you can help address the “this was predetermined” reactions. (At least the ones made from frustration or misunderstanding. You can’t do much about people acting in bad faith.) In a large community, you can’t address every single email. In fact, even if you can, you probably shouldn’t. As hard as it can be, avoid responding to every single comment to avoid looking argumentative or getting lost in the details.

During the comment period, respond to the general themes of the constructive feedback. Explain which parts you agree with, which aren’t based on facts, and which are a different conclusion. Repeat this process at the end, too. Show people that you heard them and explain why you reached the conclusion you did. This is helpful even when you do change (or abandon!) a proposal.

This post’s featured photo by Christopher Alvarenga on Unsplash

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share