Community-to-developer communication
A successful project needs a vision and people to make the vision reality. Communication from the community to developers can be an asset in creating the vision and driving the project, but it can also become a burden. Here’s a few things I think everybody should keep in mind when communicating with developers of any project.
(Useful) brainstorming
Submitting ideas is fine especially when it has been asked for. There are times when feedback and new ideas are expected or more welcome than usually. For Xubuntu this means the first weeks of a new release cycle, when everybody is planning their work for the next 6 months and discussing ways to achieve their goals. The somewhat blurry timeframe is about to end for Xubuntu right now.
A good submission is something that contains a proposed goal with a rationale with a brief comparison and arguments against the current situation (if applicable) and some (at least) half-baked thoughts on how to reach the goal.
Even if you have all this, a proposal is still not always viable. To be able to discuss certain features you need to have a variable amount of knowledge about the issues from different points of view, including but not limited to technical and social matters. Most developers won’t expect you to have all this knowledge, but please don’t be surprised or feel offended of the sometimes tight-lipped “wontfix” -style comments. They have most probably heard the same idea before…
Discuss!
When the ideas start to flow in, it’s time to start discussing them. Counter ideas are fine, but please note that they should contain the same ingredients as the original submission.
Discussing is something where all parties are free to express their thoughts. Since the amount of time to use for discussing is limited, it’s better to consider a few things before speaking.
Whenever you post, there’s a single most important thing to keep in mind: try to add to the discussion. If you can’t, even after thinking twice, don’t post. Irrelevant noise slows the progress and sometimes leads the discussion to sidetracks. If the discussion seems to keep rolling without your comment, you’ll be able to chime in if you have something that adds to the discussion. If it doesn’t, there’s most probably a reason for that.
When you make an argument against or for something please make sure it has a rationale, even if it was just your personal preference. To be more exact: always try to be objective. Being totally objective is really hard (especially if it involves any emotion), but everybody should strive for it.
All the things mentioned will save time, frustration and useless work. Saving time means there will be more time to work on the actual features. Just being loud doesn’t get things done – quite the opposite.
About realistic expectations
The ugly truth: Only a small part of ideas actualize as features or changes in a product. This doesn’t mean most of the ideas are bad. Since the ones who contribute and deliver have limited time, motivation and resources, it isn’t possible to implement all the ideas even if they were all top notch.
The other thing to keep in mind is that open source is not a democracy, it’s a doacracy – those who do, decide (what they do). This is self-evident, but saying it aloud is a real eye-opener and reminder for all of us – especially for those who are unfamiliar with open source. Anyway, here’s wishing for more patience for both sides of the discussion.
The 5-point wrap up
When submitting an idea, think it through and rationalize. Does it make sense for the project? What’s the cost in man hours and how many are you willing to submit? If you propose to replace something, be ready to compare.
When developers say something, listen to them. In most of the cases, they know better than you. This doesn’t mean they’re always right (definitely not!), but there’s a lot to learn. If you think your idea is worth discussing further, do more preparing work and propose it again – don’t expect others to.
Try to add to the discussion. If you don’t think your comment adds anything to the discussion, abstain. People don’t appreciate snarky comments to mediums exclusively designed for development discussion. If you want to have fun, there are other places for that.
Keep objective. This will be hard, especially when discussing something where you mix emotions in, like default applications. Subjective opinions are fine but even then, come up with a rationale. When discussing further, again abstain from posting unless you can add to the discussion.
Finally: those who do, decide. The majority of open source contributors are doing it for free, without any financial compensation. For many of us, time becomes the biggest obstacle; and when we only have this much, our efforts are most focused on things we like to get done. In many cases, patches are welcome: as long as you got the time, patience and ultimately skills, you can make a difference.
This article is part of the article series Communication in the community.
