Successful mentors set expectations at the start of their projects. This includes communication frequency, project goals, availability and ways of delivering feedback. While the mentor should take the lead in expectation setting, the process of creating and documenting the expectations must be collaborative. GSoC contributors and mentors need to agree on what is expected, or success becomes quite difficult.
Defining Success
Performance measures make it easier to provide feedback, to help your GSoC contributor get back on track if they veer off-course. Clearly stated measures also help you make a fair determination that a GSoC contributor needs to be removed from the program.
Get GSoC contributor input: Make sure your GSoC contributor has input into the types of performance measures used to determine success or failure. It is very important that your GSoC contributor helps create the performance measures to determine project success and failures. Your relationship should be a highly collaborative one.
Set achievable goals: Help your GSoC contributor come up with manageable project goals. Rather than defining the project as one giant chunk, help your GSoC contributor break the project goals down into smaller pieces or “inchstones” that allow a change in direction if necessary. It is sad to work the entire summer on one giant deliverable, only to find out in the last few weeks that the architecture or design is defective.
Anticipate time away: Make sure to set expectations for known or planned time away from the project, such as course work, vacation trips, holiday time, wedding, etc. Talk about how many hours or deliverables per week would be reachable goals and what amount would be a good stretch goal. With the new flexibility in the program allowing for extensions of the coding period it is reasonable to decide with your GSoC contributor that their coding period should be 16 weeks instead of the standard 12 weeks since they have a few weeks they know they will be very busy with other life happenings. Or the two of you can decide together to spread the expected hours per week over a longer period just as that is better for the GSoC contributor. For example, if the GSoC contributor is working on a 350 hour project then you both could decide to spread it over 18 weeks so the GSoC contributor would be coding ~20 hours a week, versus ~30 hours a week over a 12 week coding period.
Managing Output
Decide in advance what happens when project goals aren’t met. Remember to be flexible if your GSoC contributor has made good progress or has obviously worked hard but needs to re-scope the project at mid-term. Good project management is hard. Your performance measures will help you manage project modifications.
Plan for Slippage: Have a plan to deal with scope-creep and timeline slippage. What if something happens that prevents your GSoC contributor from working successfully for an extended period of time? At which point do you need to terminate the project? Have a plan in place for these scenarios.
Gather Feedback: Your GSoC contributor’s wishes and desires for a successful project are as important as the project goals. Make sure that you solicit and incorporate their feedback when coming up with initial goals, performance measures and communication methods.
Overall, communicate and be reasonable when it comes to your GSoC contributors. Be ready to revise project plans if an unexpected requirement or bug occurs.
Pro Tip: Ask about the weather and local stability of public services. Is your GSoC contributor using the cafe down the street for Internet access? Are there seasonal weather conditions that may lead to flooding and the subsequent inability to turn-on one’s computer? Work on a plan to address these types of environmental issues that can affect both communication and output.
Don’t Be That Person: No one likes dictators. Work with your GSoC contributor on the development of expectations, rather then barking out orders.
Project Size vs Project Length
In 2022, Google introduced 2 new features to allow more flexibility to the program: 1) multiple project sizes and 2) multiple possible project lengths. These are very different features and aren’t correlated to one another, despite what most folks think. :) A medium project (175 hours) could be a 22 week project if that is what the Mentor, GSoC Contributor, and Org Admin agree to. And a large project (350 hours) could be 10 weeks if agreed upon by all.
Project Size: Projects can be designed to be ~90 hour projects, ~175 hour projects or ~350 hour projects. When a potential GSoC Contributor submits their proposal to an organization they indicate the size of the project: small (~90 hours), medium (~175 hours) or large (~350 hours). A mentor or Org Admin can not increase the size of the project but they can contact Google Program Admins to downsize a project from large to medium or medium to small as needed - preferably during the community bonding period before coding begins.
Project Length: The Coding period of a GSoC Contributor project can be 10-22 weeks. The standard coding project length is 12 weeks regardless of the project size (small, medium or large).
All projects by default are 12 week projects. If a Mentor and GSoC Contributor agree that they want a project to be a different length, for example, 16 weeks, then they ask the Org Admin to adjust the Project Timeline on the GSoC webapp. Adjustments to a project’s timeline (and thus length) must be done before an evaluation phase begins. An Org Admin can not change a midterm evaluation deadline once the midterm evaluation period has begun (same with final submission period).
We suggest a small project should not be longer than 12 weeks in most cases.
Sometimes a project is extended to the 18 or 20 weeks because the GSoC Contributor is unable to really get their project going until a few weeks or so later into the coding period due to other commitments (exams, graduation, wedding, etc.). This is why we have designed the program to allow a medium or large project to be anywhere in the 10-22 week period.
Google Admins have given guidance on the dates for a project to make it as easy as possible for an Org Admin to be sure they are giving the evaluation periods the appropriate number of days for all participants. The dates can be found as a link when the Org Admin opens a project under the timeline section.
Reminder emails are sent to all Assigned Mentors on a project and to the GSoC Contributors based on the Project’s length. Each Mentor and GSoC Contributor will receive a reminder email 10 days before their evaluation period begins and another reminder the day their evaluation period opens. If a Mentor or GSoC Contributor has not submitted their evaluation (or final submission) 24 hours before their deadline they will receive a final reminder email.
Important Note: Org Admins have the final say in whether they want to allow various project lengths or if they want all of their projects to be the standard 12 week projects. While the flexibilty is great for many, it can be more cumbersome for the Org Admins as they have to keep track of the various dates for projects (available from their Org Admin view of all Projects for their org).