Managing the Plan

One important tool is the creation of a strategic plan. The phrase “project plan” frequently elicits a Pavlovian response of groans, shrieks and malaise in techies. An even more severe reaction has been observed in open source communities. So let’s talk about a “strategic plan” instead, and how it can help your contributor be successful.

Creating a Strategic Plan

The application process assists in developing a good preliminary outline of a strategic plan for the project. To increase the probability of program success mentors should spend time with contributors, and the development community, refining the plan developed in the application period as part of the proposal.

Please note that even though you and your contributor can decide to change the project from what was originally proposed, both of you need to agree on the change. It is important to make sure that the contributor has the appropriate background knowledge for the new changes.

A good strategic plan includes:

• A high-level design document: Think about the architecture and design of the new feature or enhancements that you are making to your community’s project. Take some time to teach your contributor to think about usability by writing a few quick use cases and scenarios, and consider the introduction of any new dependencies.

• Progressive milestones that build on the previous work: At the completion of each milestone you and your contributor should take the opportunity to celebrate the accomplishment and reflect upon it. Using progressive milestones also gives you a good measure of how far you have come, which can be very useful during periods of frustration. Additionally, if you don’t reach all of the final goals of the project, you will have tangible achievements to point to when reviewing progress with your contributor. Reinforcement of a contributor’s tangible accomplishments encourages them to stick around and helps to create life-time contributors.

• Target completion dates for each milestone: In reality, completion dates are going to move. Nonetheless, a target date gives you a time frame for closure and helps control “scope creep”. Coach your contributors in how to recognize that a milestone is going to be missed, and to notify the project participants before the dates passes.

• Tasks associated with each milestone: Because your milestones are most likely going to be chunks of code, each milestone needs to include both testing and documentation around that particular “chunk.” This approach helps guarantee that you and your contributor don’t end up with a pile of code that hasn’t been tested or documented at the end of C4GT.

Following the Plan

After you create a strategic plan, you actually need to follow it. Some ways you can use your strategic plan to stay on track are:

• Collect regular status reports: Status reports are an important communication tool. They are also important in making sure that time-line slippages and scope creep are addressed in a proactive manner. You do not want to find out two weeks after a milestone due date that your contributor has slipped the date because they have been unable to solve a simple problem.

• Check off associated milestone tasks:Keep track of tasks, and then indicate when they are completed. This can be as simple as keeping an informal to-do list in that is referenced in weekly status reports.

• Set an expectation of prior notification of missed deadlines: Your contributor might miss project deadlines. Make sure that they understand that it is important to notify you of the missed deadline well in advance. Understanding how long something is going to take to complete is a valuable skill, but it is one that is learned through ongoing evaluation.

• If your contributor misses a deadline, make sure you discuss why: Helping your contributor understand where they become bogged down or stuck helps with future strategic plan development. Remember that you are cultivating a long-time contributor.

• Be a good example: If you, the mentor, need to miss a deadline, make sure you communicate this to your contributor well in advance.

Delivering Feedback

Throughout the project you should be delivering effective feedback to your contributor about their code, communication, and documentation.

• Deliver feedback early: Don’t wait until several issues have come up, or until your contributor has impressed you multiple times with their efficiency. Let them know right away what you think about their work.

• Make a point to give positive feedback: The open source community parcels out compliments all too frugally. When a contributor completes a task on time, and especially when they exceed your expectations, let them know! Early praise is a far better motivator than late criticism.

• Don’t avoid critique: Try to put yourself in your contributor’s shoes, and consider how you might want to hear constructive criticism. Phrase suggestions positively. If criticism is personal in nature (i.e. tone of an email, timeliness or other non-code issues), deliver it in private rather than in a public forum.

• Pro Tip: Don’t let the development of your design document become your C4GT project. It’s useful to set a date for completion of your strategic plan and add a “Start of Coding” milestone. Since the timelines are short, ensure that the strategic plan are locked in the first week itself.

• Don’t Be That Person: Don’t be overly-critical of date slippage. It happens. Fanatical adherence to dates does not lead to successful project completion, nor does it make your contributor feel excited to contribute to your community long-term.