Best Practices
Effective communication between mentor and student is absolutely vital to a successful and rewarding GSoC experience. Here are some tips for encouraging good communication:
Share contact details: Swap contact information with your student and org admin early on. If your contact information changes, be sure to tell people, and make sure your student does too. Be sure to keep the org admin informed about when you may be unavailable to your student, so that they are not caught unaware when your student contacts them.
You need to take care if you are planning a trip during the summer, especially if it is more than a few days, or near milestones in the GSoC timeline. If you coordinate with your student beforehand and give them sufficient work to chew on, it can go smoothly. What you don't want is for your student to be blocked on something while you are inaccessible and do nothing until you return. Make sure to give your student many different tasks to work on, so that she can work on something else if you are not available. This is a great time to utilize a secondary mentor to act as a backup in your absence.
Choose communication channels: Decide upfront how you are going to communicate with your student and what type of technology or medium you are going to use. Don't wait until mid-way through GSoC to figure out that one of you can't get your microphone working on your desktop for voice chat.
It's good to make use of multiple means of communication, as different platforms can complement each other. Instant methods like IRC or IM are great for getting a quick answer or for interactive discussion, but require both parties to be available at once. Public communications are generally preferable to private ones.
Although many people prefer text-only communication, it is very helpful to talk on the phone or video-chat with your student at least once at the beginning of the program. Hearing a voice or seeing a face can help people feel more connected, creating a sense of mutual respect and responsibility.
Decide on the frequency of reports: Discuss and decide the frequency and form of status reports upfront. Many organizations require students to deliver weekly status reports. Make sure you clearly delineate in what format the reports should be delivered and what information needs to be included. Providing an outline or template can be helpful.
Establish frequent chatter: You really want to be hearing from your student more often than once a week, as this is a long time for a student to be stuck or heading up a blind alley. Be sure to encourage and instigate communication throughout the week.
Provide a safe environment: Create an environment in which your student feels comfortable enough to ask questions that may sound "stupid". This will help the student to avoid getting stuck, and foster positive mentor-student and student-community relationships. Good relationships are extremely important for GSoC success, and for fostering and encouraging long-term contributors.
Here are some ways to help your student understand that his question is valuable:
Avoid gruff “RTFM” replies: It's likely the student will ask questions which are answered somewhere in your project's documentation. However, do take a few moments extra to politely point to the information, or you'll risk the student feeling reluctant to ask next time he has a question.
Ask some stupid questions yourself: Chances are your student knows some things you don't know or that you’ve just forgotten. Don't be afraid to ask your student questions.
Be inclusive: If you're asked a question which someone else in your project could answer better, put your student in touch with them. Invite your student to participate in your community events, not just the core development processes. Invite your student to attend group retreats or related conferences.
Introduce your student to the community's communication style: Some groups have developed codes of conduct, such as the Fedora IRC Helpers Code of Conduct (http://fedoraproject.org/wiki/IRC_helpers_code_of_conduct), which help initiate new members and guide the interactions of existing members. You are encouraged to read the code of conduct and think about which issues and solutions might apply to your group.
Follow mailing list etiquette: The GSoC mentors mailing list has more than 3000 subscribers. If you have a question for the Google team, mail ospoadmin@gmail.com instead of the list. Please take a moment to review list etiquette (http://www.gweep.ca/~edmonds/usenet/ml-etiquette.html).
Address communication disconnects: When working with people for the first time, a best practice is to assume that they do not mean any harm. If your student makes a comment via email that offends another member of the community, it's appropriate and constructive to speak up and address the issue. Assuming that the comment was the result of misunderstanding, rather a result of malice, allows you to ask questions and help your student adjust to your community's communication style.
After asking questions, you can then offer an explanation to a person or a suggestion on how they could behave or phrase their comments differently in the future. When offering coaching on how to behave, be mindful of embarrassing your student in public about what's happened, or demanding apologies. If possible, talk to your student one on one, using an immediate communication medium like IM, IRC, the telephone or a face-to-face conversation. This is better than sending email. Remember that you're telling someone that they did something wrong; keep in mind how you'd feel if someone was telling you that you'd made a mistake.
Apologize Effectively: Making apologies is a fact of human life, and open source communities are no exception. In the event that you or a student finds themselves needing to make an apology, there are a few things that might help you apologize effectively:
- Make the apology as soon as possible
- Make it clear in the subject line that you're apologizing
- Make it an honest apology and not a defensive statement in disguise
Giving and Receiving Criticism
Mailing list culture and public code review can be a rude awakening for newcomers. Submitting a patch to a mailing list might be a student's first experience with public critique of their code.
Project policies vary widely on how contributions are treated. Some encourage committing early and often, hopefully maintaining a stable branch for bug-fixes. Others refuse to commit code to the core repository until a patch is fully discussed, tested and documented. Most projects lie somewhere in between.
All projects engage in some form of code review and the inevitable criticism. Having people look at and ask questions about your code is a fact of working in the open source world. Direct code review is one of the great strengths of open source development. Direct review helps people hone their coding skills and learn rapidly from others. Bugs are found quickly and fixed. The whole process is documented in source control repositories and mailing lists and made available online.
Here are some ways that you can help students prepare for code review:
- Provide example mailing list threads or a list of the types of questions that are asked about code.
- Direct students to review coding standards that apply to your project.
- Go through an example code review on the student's first code sample submission that matches as closely as possible the process that your project normally uses.
People are more likely to respond positively to criticism from those that they trust and respect. Try introducing students to the people that are likely to comment on their code, and explaining the role that those people play in the group. Also, encourage students to both defend technical decisions, and be gracious in admitting mistakes.
Code, in addition to being mathematical and scientific, has been compared to poetry or creative writing. Most developers associate a sense of ownership and creative discovery with their code. You may have "gotten over" the bruised ego you received the first time that someone criticized your variable name or algorithm choice. However, your student may be experiencing this pain for the first time. A simple "thank you" when students publish code, send email to a mailing list or make other contributions goes a long way.
Make an effort to assist a student in their first steps into your community. Offer to proofread emails, blog posts, or patches. You don't want to do all the work for them, but you can help students feel confident in their communication, especially when they're just starting out.
Pro Tip: A good status report should include a few items that went well during the previous period, and a few problems that were encountered and how they were addressed.
Don't Be That Guy: Don’t ever give your student the impression that you think that only stupid people ask questions. Be nice. Remember that you were once a beginner.