Share the responsibilities!
People in open source should try to make decision making in communities more inclusive, and essentially, more demographic. In other words, we need to start trusting others more.
On the other hand, every project needs leaders. In the ideal situation a leader is somebody who is able to empower the team to reach its goals, and more.
Leaders, let others take responsibility
Giving people responsibilities doesn’t mean you can’t be involved with the process. Ultimately, it comes down to the leader to define how important a feature is for the project at this time. The importance should roughly correlate on how much direct involvement the leaders or others in the team should have with drafting and implementing the feature.
Major features usually take longer to implement and need constant communication. Minor features might not need even any monitoring from all parties before they enter the discussion and polishing phase.
In both cases, people need to have the feeling that their work is both appreciated and that it can make a difference. Essentially, people need to feel accepted. Engaging people within a project is much about balancing the management. Too much micro management on minor issues or too little management on major issues will both eventually lead to the situation where the leaders end up doing everything by oneself.
Getting things done
Deadlines are important. Essentially, deadlines allow projects to release, and ultimately, improve the products for the users.
When setting deadlines, define them clearly. If you don’t specify deadlines, you can’t expect people to meet them either. Define how critical different deadlines are. Finally, specify what the implications of not making the deadline are. In open source, this usually means your work isn’t going to be included in the release. While it’s self-evident it’s good to say it aloud.
When taking work items and engaging with deadlines, keep it real. Don’t try to change the world in one release. If you can, share and delegate work items which aren’t critical (for you). If the release schedule still looks unrealistic, simply postpone some items for the next release. Finally, if and when others take release-essential work items, make sure they acknowledge that.
Deadline days are a good time to learn something. Review how you did with your work items. As a leader, review how your team did. Don’t be angry to people for not finishing things, if you couldn’t have done them yourself. If somebody had a release-essential task and didn’t deliver on time, something undoubtedly went wrong. Before expressing your disappointment, think if you could have given support that enabled finishing the work item.
Together, individually
Keeping an open source project running many times equals to keeping people feel like their work is worth something. Some people will need more or less reminding their work is appreciated to keep them contributing, some people will have this feeling without encouraging because their work is valuable for themselves.
Whatever the case, we all need to remember that while individuals ultimately make or break the project, we’re doing it together. A nice word here and there doesn’t take all your time and it might be just the thing somebody else needed to keep up the motivation. For more reasons to be nice to each other, read On Hackers and Depression by Christopher Webber.
How can you improve your community?
I’m interested in hearing your thoughts about improving communities and steering them to be more democratic when beneficial.
Do you agree or disagree with me? How do you think communities can be improved? Is there something you think the Xubuntu team should do to improve our developer community? Share your views!
This article is part of the article series A day in an open source project.