GSoC Mentoring - 1

GSoCMentoring: StudentCommunication

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 communications:

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 the 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 (e.g. posted to your development list or on their blog). 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 frequent communication for rapid question and answer and lightweight mentoring throughout the week.

Provide a safe environment: Create an environment in which your student feels comfortable enough to ask questions that she may believe to be "stupid". This will help to avoid them getting stuck, and fosters positive mentor-student and student-development community relationships, which is extremely important for GSoC success and fostering and encouraging long-term contributors. Some ways to help your student understand that his question is not stupid but an important part of the project's success:

Avoid gruff “RTFM” replies: It's likely the student will ask questions which are answered somewhere in your project's documentation, but do take the 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 has some area of knowledge that does not pertain to your current skill set, or maybe you’ve just forgotten the answer. Ask her. Or if you're asked a question which someone else in your project could answer better, put your student in touch with them.

Be inclusive: Invite your students to participate in your community events, not just the core development processes. This could include group retreats or related conferences that members of your community are planning to attend.

Introducing your student to the community's communication style: Some groups have developed codes of conduct, such as 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.

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   

Addressing communication disconnects: Whenever working with people for the first time, a best practice is to assume that they do not mean any harm. If your student, for example, 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 individual 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 1:1 using an immediate communication medium like IM, IRC, the phone or in person is better than sending email. Remember that you're telling someone that they did something wrong, and keep in mind how you'd feel if someone was telling you that you'd made a mistake.

Effective Apologies: 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, however, 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 free and open source world. The directness around code review is one of the great strengths of open source code. People hone their coding skill and learn rapidly from others. Bugs are found quickly and fixed. And generally, 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 goes through

People are more likely to respond positively to criticism from people 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 have a sense ownership and creative discovery associated with their code. You may have "gotten over" the bruised ego you received the first time that someone told you that a variable name, or an algorithm choice you made sucked. But a student may be experiencing this for the first time. Stay aware of the difficulty involved being told that you've made a mistake, and be encouraging about the fact that the students are participating in the first place. A simple "thank you" when students publish code, send email to a mailing list or make other contributions go 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 solved -- or not.

Don't Be That Guy: Don’t reinforce your student’s perception that by asking you a question, you automatically assume they are indeed stupid.  Be nice.  Remember you were also once a beginner.

There has been error in communication with booki server. Not sure right now where is the problem.

You should refresh this page.