Tutoring Plan. Manual
This manual is based in "Google Summer of Code Manual". It is licensed with Creative Commons SA-BY 3.0.
Tutoring can be a very rewarding experience. However there are specific skills that you need in order to be effective; even experienced tutors can improve these skills. This chapter highlights some of what it takes to be a good tutor.
Are you already part of the U++ community? If you are not then you are not going to be effective at introducing a person to the local culture and practices. Similarly, you are not likely to be able to propose guide.
Are you willing to dedicate time? It is difficult to put a number on such a subtle art as tutoring. You should seriously consider your prior tutoring experiences and your available time before committing to this role. If you really don't want to or really won't be able to tutor, then don't offer.
Be Prepared to Seek Help. At all times don't forget that you have access to people, tools and resources that can make your job much easier and make you a better tutor. Make use of other tutors in your organization when you have a difficult situation with your beginner.
Share contact details: Swap contact information with your beginner and Tutoring org. early on. If your contact information changes, be sure to tell people, and make sure your beginner does too. Be sure to keep the Tutoring org. informed about when you may be unavailable to your beginner, so that they are not caught unaware when your beginner contacts them.
Choose communication channels: Decide upfront how you are going to communicate with your beginner and what type of technology or medium you are going to use. Don't wait until mid-way 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.
Provide a safe environment: Create an environment in which your beginner feels comfortable enough to ask questions that s/he may believe to be "stupid". This will help to avoid them getting stuck, and fosters positive tutor-beginner and beginner-development community relationships, which is extremely important for success and fostering and encouraging long-term contributors. Some ways to help your beginner understand that his question is not stupid but an important part of the project's success.
Avoid replies: It's likely the beginner 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 beginner feeling reluctant to ask next time s/he has a question.
Ask some stupid questions yourself: Chances are your beginner has some area of knowledge that does not pertain to your current skill set, or maybe you have just forgotten the answer. Ask her/him. Or if you're asked a question which someone else in your project could answer better, put your beginner in touch with them.
Be inclusive: Invite your beginner to participate in your community events. This could include group retreats or related conferences that members of your community are planning to attend.
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 beginner, 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 beginner 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 beginner in public about what's happened, or demanding apologies. If possible, talk to your beginner 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 beginner 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
Groups of humans come up with abbreviations and slang that are meaningful inside the group, but not necessarily to outsiders. Encourage newcomers to ask questions when they don't understand a term, a joke or some arcane bit of project lore. Remember that you were the newbie once too, and take a few minutes to explain. The best jokes are the ones that everyone is in on. Letting your beginners in on these jokes helps makes them feel more included in your community.
Here are a few useful resources for teasing out meaning from initialisms, acronyms and abbreviations:
Urban Dictionary (http://www.urbandictionary.com)
Webster's Online Dictionary (http://www.websters-online-dictionary.org/)
Acronym Finder (http://www.acronymfinder.com/)
A to Z word finder (http://www.a2zwordfinder.com/) -- also great for cheating at Scrabble or other word games
Volunteerism and Gift Economies
Donated and free time are the life blood of open source projects. Many individuals contribute their time and energy without any expectation of compensation or even a simple thank you in return.
This culture may be unfamiliar to beginners, and require explanation.