Effective communication between mentor and GSoC contributor 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 GSoC contributor and org admin early on. If your contact information changes, be sure to tell people, and make sure your GSoC contributor does too. Be sure to keep the org admin informed about when you may be unavailable to your GSoC contributor, so that they are not caught unaware when your GSoC contributor 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 GSoC contributor beforehand and give them sufficient work to chew on, it can go smoothly. What you don’t want is for your GSoC contributor to be blocked on something while you are inaccessible and do nothing until you return. Make sure to give your GSoC contributor many different tasks to work on, so that they 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. Be sure another mentor (or org admin) is available to complete the evaluation if you’re unavailable.
Choose communication channels: Decide upfront how you are going to communicate with your GSoC contributor 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 or Slack channels 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 some people prefer text-only communication, it is very helpful to talk on the phone or video-chat with your GSoC contributor at least once at the beginning of the program and again midway through. Hearing a voice or seeing a face can help people feel more connected, creating a sense of mutual respect and responsibility. Feedback from GSoC contributors has made it clear they really enjoy having weekly or bi-weekly video chats with their mentors or community members.
Decide on the frequency of reports: Discuss and decide the frequency and form of status reports upfront. Many organizations require GSoC contributors to deliver weekly status reports, some require daily reports. Do not wait until the midterm to get a status report, that never ends well. 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 GSoC contributor more often than once a week, as this is a long time for a GSoC contributor 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 GSoC contributor feels comfortable enough to ask questions that may sound “stupid”. This will help the GSoC contributor to avoid getting stuck, and foster positive mentor-GSoC contributor and GSoC contributor-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 GSoC contributor understand that her question is valuable:
Avoid gruff “RTFM” replies: It’s likely the GSoC contributor 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 GSoC contributor feeling reluctant to ask next time they have a question.
Ask some stupid questions yourself: Chances are your GSoC contributor knows some things you don’t know or that you’ve just forgotten. Don’t be afraid to ask your GSoC contributor questions.
Be inclusive: If you’re asked a question which someone else in your project could answer better, put your GSoC contributor in touch with them. Invite your GSoC contributor to participate in your community events, not just the core development processes. Invite your GSoC contributor to attend group retreats or related conferences.
Introduce your GSoC contributor to the community’s communication style: Many groups have developed codes of conduct, such as the Fedora 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. Please also check out Google’s Community guidelines.
Follow mailing list etiquette: The GSoC mentors mailing list has more than 16000 subscribers. If you have a question for the Google team, mail gsoc-support@google.com instead of the list. Please take a moment to review list etiquette.
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 GSoC contributor 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 GSoC contributor 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 GSoC contributor in public about what’s happened, or demanding apologies. If possible, talk to your GSoC contributor 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 GSoC contributor 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 GSoC contributor’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 GSoC contributors prepare for code review:
- Provide example mailing list threads or a list of the types of questions that are asked about code.
- Direct GSoC contributors to review coding standards that apply to your project.
- Go through an example code review on the GSoC contributor’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 GSoC contributors to the people that are likely to comment on their code, and explaining the role that those people play in the group. Also, encourage GSoC contributors 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 GSoC contributor may be experiencing this pain for the first time. A simple “thank you” when GSoC contributors publish code, send email to a mailing list or make other contributions goes a long way.
Make an effort to assist a GSoC contributor 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 GSoC contributors 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 Person: Don’t ever give your GSoC contributor the impression that you think that only stupid people ask questions. Be nice. Remember that you were once a beginner.