The editorial calendar plugin for WordPress started as a family weekend project and it remained the stuff of evenings, weekends, and other stolen moments for a few weeks after that. But eventually it was stable enough to invite other people and we needed to take a set of random ideas, documents, and code and turn them into a project that welcomed other contributors.
Making a project inviting is essential if you ever want it to graduate beyond hobby status. Successful projects have a clear path for welcoming new comers. Successful projects are open projects and that means taking the time to make everything neat and organized.
Opening up the editorial calendar took three major steps:
Step 1. Consistency
Prototypes are messy. You spend your time wondering if something will work at all instead of planning for the future. Various ideas come together and are discarded just as easily. The result looks more like trash than treasure.
Before I was ready to share my calendar prototype with other people I needed to clean it up and make it consistent. Make sure I did the same things in the same way. Cleaning up the prototype took about a week.
Step 2. Documentation
People only know what you tell them. Other people, even other programmers, weren’t going to know how my program worked unless I explained it clearly. Just giving someone the code is never enough. I added many comments to my code, but code comments are more like sticky notes than blueprints. They’ll tell you how the brake pads attach, but not how many wheels your car has.
Other contributors need to know why the project works the way it does. They need to understand what I was thinking before they can embrace it and make it their own. That type of deep understanding can’t come from the details, it takes a grasp of the big picture.
I wrote my big picture document as blog post. That way I can share it with the team and anyone else that might be interested in the future.
Step 3. Bug bounties
Bug bounties are easy descriptions of simple problems in the product. They’re good places for new contributors to start.
Showing your work to others is scary. It causes a tendency to polish the hood a little too much before unavailing the car. That’s a mistake. Most people are attracted to 80 percent projects. A good 80 percent project has clear goals and a strong foundation, but also enough cracks to grab onto. Polish it up to 100 percent and new members won’t know where to start.
Bounties give new team members an easy first step. I defined four simple bug bounties. I could have easily fixed these areas myself, and I could do it faster than anyone else. At this stage I have more knowledge about my project than everyone else in the world, but that’s what I’m trying to change.
That extra knowledge is what makes this stage so tricky. My ego tells me I don’t need anyone’s help, but it’s wrong. Letting other people take the time they need to learn the project is more important than fixing the problem s right now. To the engineer in me that makes all the sense of combing your hair with peanut butter, but it’s true.
And then I was ready to begin. I had the first meeting with the rest of the team and we started making the project real.
Coming up: Next week I’ll introduce you to the rest of the team and show you a little bit about how we communicate.