The Fedora Project has always been aimed at encouraging participation. Free/libre and open source software continues its forward momentum and increasing pace through the growth of community and contribution. And Fedora plays a large role in that motion, through our rapid release cycle, our dedication to working with upstream software communities, and by making sure that everything we build is 100% free and redistributable. But we are not just a distribution — we are a project made up of teams, and individuals: people working together in pursuit of common goals. The more people that help, the more we can accomplish. And therefore, as free/libre and open source software advocates we need to constantly ask ourselves, Am I doing what I can to make it easy for others to help?
On many Fedora teams, we have a robust membership from all around the world. We can see the effects of solid leadership and the lowering of barriers resulting in wider participation and contribution. But in some places we could be doing better. In that vein, I ask team leaders and principal contributors: How many steady contributors do you have working on your immediate team? How many people can you count on to perform key tasks? And at the risk of sounding morbid, I’ll ask a very important question that’s simply a good way of summing up this idea: What would happen if you got hit by a bus tomorrow?
OK, I warned you that was a little morbid. Forget about the risk of death, or at least injury, but focus on the central idea. Maybe we could sum up in a more humorous fashion. My 6-year-old son loves dinosaurs, so here’s a different way to ask that question: What if you were eaten by dinosaurs?
Yes, it’s even more unlikely than the bus scenario. By restating the question in a silly way, I hope it keeps you from worrying in concrete terms about your loved ones or your insurance. That way, you can treat the question as an abstract problem in community building. But that question still has concrete solutions. The point is, if for some reason you as a team leader or participant were suddenly out of the picture without warning, what would happen to the work your team does?
If you’re doing a solid job of lowering barriers, the answer should be “almost nothing.” The team should be able to keep chugging along, more or less. Certainly all contributors are important — you’d be missed, and we’d make it a point to hunt down those pesky velociraptors and make them pay! But the overall team’s ability to be healthy and vibrant shouldn’t hinge on any one person as a linchpin.
Can other people do your work if you’re out of commission? Can Fedora continue without you manning the wheel? If not, it’s time to step back and look at what you’re doing to improve that situation.
- Are the procedures for your team well documented, in an organized fashion, somewhere people can find and read them? For many people, documentation is never as fun as the “real work,” at least not for people who don’t love writing documentation itself as the real work. (Shout out to our Docs team for being in the latter category.) But if you were eaten by dinosaurs, that very documentation helps people find the information they need to keep your work going. Rather than have contributors flounder around trying to find random people on IRC to figure things out, you can promote efficiency and motivate new contributors by having material that will tell them how to work through processes.
- Does your team have a plan, that includes goals for the immediate future? Every team has a couple of goals its members want to accomplish. Some are very broad vision statements, but to encourage participation you need at least a couple of achievable near-term goals toward which your team members can work. By tracking their progress in regular meetings, and reporting that progress to the overall Fedora Project, you make it possible for interested people to pitch in where needed. This process also encourages the team to be honest with itself. The ability to look back on a release and say, “We achieved goals X and Y, but still need to do some hard work to attain Z,” is a powerful motivational force. Never underestimate the empowerment that comes from a job well done.
These two items are completely equal in importance. Just as important as the plan is to make sure you are building a team of contributors that helps you get there! The most successful community projects ensure that the most knowledgeable people don’t make a point of performing every difficult task. Instead, they make it a point both to spread that knowledge so others can help with the work, and to enlist the team’s help to establish and support achievable goals.
If you find that you as a community team leader spend a lot of your time saying, “I wish I had time to work on this cool new idea, but I have too much of this other, established work to do,” then it’s time to evaluate how you’re doing as a community builder. If you make it possible for other people to help — and, along the way, to succeed in achieving their own goals as participants — you are doing far more for Fedora in the long term. And in the event that you do get mistaken for a convenient, bite-sized package of Oscar Mayer lunch meat by a passing T. rex, you also make it possible for Fedora to continue that forward momentum we talked about earlier!
So in the vein of this post, I want to issue a challenge to each of our teams, to do two things during the next 10 days that will help make Fedora 12 the best release yet, and help make the Fedora community an even better place to contribute to free software:
- Check to see that all the processes you use are documented on the Fedora Project wiki — and if not, make plans to do so. Don’t worry about skillful writing; worry only about documenting what you do.
- Come up with one or two simple goals that your team wants to achieve by F12 release, and announce them to the community via the Planet (and any other way you’d like).
We’re embarking on our 12th release, and all signs point to the next release, just like the others before it, to be the best one yet. We have an enormous and amazing community of participants and contributors, who do more than just spread the word — they lead by example. Let’s each of us make sure we’re doing all we can to ensure our teams’ and our teammates’ success, by giving them the tools they need to help as fully as possible.
What would really help is if a person from the docs team would be willing to put in time to help us document what it is that we do. I’m massively intimidated by an empty wiki page, just having a human to talk to and provide unedited snippits of information would go a long way to having all our stuff documented.
@Jesse: That is a superb suggestion, having a Docs team member embedded with another team. The first step to making that happen is to check in on the fedora-docs-list and lay out what you need. While you probably don’t want to train an additional person to run every actual process in detail — which is, in a sense, what you’re trying to avoid through documenting — what tends to work well is to pick a set of processes, sketch them out briefly, and then let the Docs person work through them, finding holes, asking questions, and writing the processes up in their entirety.
If you find yourself in this specific situation for Release Engineering, then I’m twice as happy I wrote this blog post. Not because of Schadenfreude, but because until now it was more of a general suspicion in my head that we have pockets of people in need! Heck, if you had time to do some of this at FAD or in Berlin, I’d be happy to help with it myself as a former Docs guy. We could start by just putting together a list of each process you work on routinely (or per-release), and start drilling down after that.
Rather than the bus or dinosaur, I prefer to say “what if you won the lottery and retired to the Bahamas tomorrow?” More positive by half 🙂
@Adam: Well done sir! Lottery ftw. (But raptors are more fun to joke about, you gotta admit.)