The student and organization application process to GSoC helps all participants think about how to run the Google Summer of Code at a community level. 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 student be successful.
The GSoC application process assists in developing a good preliminary outline of a strategic plan for the student's accepted project. To increase the probability of program success you should spend time with your student, and your development community, refining the plan developed in the application period. This can be done during the community bonding period. 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 student 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 student 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 student. Reinforcement of a student'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 students 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 of code, each milestone needs to include both testing and documentation around that particular "chunk." This approach helps guarantee that you and your student don't end up with a pile of code that hasn't been tested or documented at the end of GSoC.
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 student has slipped the date because they have been unable to solve a simple problem.
Check off associated milestone tasks: Find a way to 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. You can also use the project management software that the rest of your organization uses. Do what works best within your community, but make sure you do something.
Set an expectation of prior notification of missed deadlines: Your student is going to 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 student misses a deadline, make sure you discuss why: Helping your student 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 student well in advance.
Throughout the project you should be delivering effective feedback to your student about their code, communication, and documentation.
Deliver feedback early: Don't wait until several issues have come up, or until your student 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 student 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, but don't be a jerk: Try to put yourself in your student'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. When in doubt, ask for advice from more experienced mentors or from your organization's administrator.
Pro Tip: Don't let the development of your design document become your GSoC project. It's useful to set a date for completion of your strategic plan and add a "Start of Coding" milestone.
Don't Be That Guy: 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 student feel excited to contribute to your community long-term.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.