This is the second in a series of three posts on DOs and DON’Ts for Google Summer of Code students, mentors, and organization administrators. The first post dealt with students while this post features mentoring organization administrators. Organization administrators (org admins) oversee the overall progress of a mentoring organization and its students throughout the program. Based on our experience with Google Summer of Code, we’d like to share these tips and antipatterns with you to raise awareness and help other org admins avoid the same mistakes we’ve made. For even more advice, check out the mentor/admin guide.
| DO | DON’T |
| Track the timeline and projects closely. Most mentors and students need a helping hand, and you can only provide this if you’re aware of the deadlines yourself. Be sure both mentors and students are aware of their next steps. Also, keep track of the progress of each project, perhaps with a spreadsheet filled in by the mentors—this gives you time to deal with major problems before midterms/finals, when little choice exists besides failing the student. | Fail to follow up on mentors and students. It is easy to lose your perspective of deadlines and progress. If you don’t stay on top of them and make sure they are aware of their responsibilities it can result in unnecessary failure of students or embarrassment for your organization. |
| Start small. Everyone gets the most out of Google Summer of Code when the orgs are on top of everything and everyone knows what’s going on. You can achieve this most easily with only a small number of mentors and students. Successful orgs tend to be invited back, so plan for success; there is time to grow later. It’s much better to have a few overwhelming successes than many borderline cases and failures. | Take on too many students. Most new organizations try to get as many slots as they can. This is, however, rarely a good idea. They greatly underestimate the resources needed to mentor a group of students in a program like Google Summer of Code. Taking on too many students almost always leads to a poor project outcome and integration of the students in the community and thus low retention rates. |
| Ensure you can support the number of students you request. The requirements for project voting and ordering become much more severe as the number of students, mentors and projects increases; it’s nowhere near a linear scale. After coding starts, you still need to track projects to make sure your overall program is running well. Avoid methods that rely on significant time commitment from you, and instead distribute the effort to mentors and students. | Grow too quickly. Once you’ve succeeded with a couple of students, it can be tempting to think you’ve figured everything out. But things that work great on a small scale can fail wretchedly when scaled up. For example, asking every mentor to read every proposal might work fine when there are only 10 proposals, but it doesn’t function nearly as well when there are 100. |
| Plan for communication throughout Google Summer of Code. There are times throughout the program when you need to let the mentors and/or students know about certain things, like deadlines. Plan for this from the start of the program by, for example, subscribing everyone to a dedicated mailing list. Make it clear from the start that mentors and students can approach you to discuss nontechnical problems, so they know they can rely on you as a resource. Overall, you need to be visible and keep people motivated throughout the process—and follow up with students afterwards to encourage them to become long-term contributors. | Forget to keep clear lines of communication with the mentors and students. Discovering you need to get in touch with a student or mentor and finding you can’t reach them is trouble in the making. If you don’t have backup contact details for mentors, it’s easy for them to disappear—particularly if your primary method is an online chat like IRC or XMPP. |
| Work out your responsibilities in advance. If you’re a new org, it may not be obvious what you need to do to support the mentors and the students. Make sure both you and your mentors have the same idea about your role. Particular things could be: If your organization has IRC meetings, you need to make sure they run smoothly. If your organization requires blog posts, or mailing list updates, you have to make sure these happen. Once the program starts your enthusiasm needs to continue because it feeds mentors and the students. To maintain your excitement, think about the benefits your organization receives at the end of the program for every successful project: new code and new contributors! | Be enthusiastic in the application stage but stop when the projects start. It’s relatively easy to keep enthusiasm high when it’s early in the process as your tasks are obvious (apply for Google Summer of Code, get the ideas page sorted, get the mentors lined up, set up mailing lists, etc.). If mentors or students sense you are distracted or no longer dedicated to your role as organization administrator, their enthusiasm for the project will likely decrease. You are the glue that holds everything together and everyone will look to you to keep things moving forward. |
| Coordinate mentors early to get a high-quality ideas list. At the meetings for rejected orgs, the most common theme by far is “you can improve your ideas page.” Look at other orgs’ ideas pages for this year and for last year, as well as the mentoring guide. New organizations often ask whether their ideas are too long, but they usually aren’t; clarity and detail are highly desirable. To maximize student interest in your organization, you should have an ideas page well in advance of the deadline for org applications. Also be sure to give the students what they need to get excited about the projects and contact you; provide enough context to convince them why this idea matters. If there are specs for the projects, link to them and be sure to provide contact details for each idea. Handling student interest in the run-up to applications can be very time-consuming, plan accordingly. | Construct your ideas page at the last minute. Students look at the ideas pages long before orgs are selected; they’ll pass your organization by if you don’t have ideas ready when they first start researching the orgs. Failure to prepare early has particularly large consequences for umbrella orgs, where there is a logical disconnect between several developer communities, but it also holds true for individual projects. To avoid “writer’s block,” you can start with a high-level idea of what types of projects your org wants to sponsor and work from there. |
| Arrange infrastructure in advance. Most projects will require some infrastructure to be in place for students to work effectively—whether it’s a committer account, repository creation, students knowing where they should post their code, or simply getting them subscribed to relevant mailing lists and taught the proper protocols. Everything should be in place for students to make their first commits as a true member of your organization’s community on the initial day of coding. There’s also a brand-new mailing list for supporting new org admins called gsoc-veterans that you can turn to for advice (new organizations will be invited soon). | Block projects from starting on day one of the coding period. If technical difficulties prevent students from being productive when coding should have started, it instantly lowers the scope of what they can accomplish during the summer and may prevent them from finishing their projects. For example, if they don’t know how to use your version-control system or don’t have commit access, they’ll be mired in tangential problems instead of coding. |
Making Google Summer of Code the best possible program requires a commitment to excellence and preparation from participants at every level. In this post we’ve provided suggestions for org admins, and in the last post in this series we’ll cover mentors. Whatever role you would like to play in Google Summer of Code or a similar program, read everything you can find so you know what you’re getting into. Good luck, and have fun this summer!
By Donnie Berkholz, Lydia Pintscher, and Kevin Smith, Google Summer of Code Administrators for Gentoo & X.Org, KDE, and XMPP Standards Foundation, respectively
0 Response to "The DOs and DON’Ts of Google Summer of Code: Organization Administrator Edition"
Post a Comment