Hi
Thank you so much for volunteering to help at our Open Source Comes to Campus event! You may be wondering what, specifically, we're expecting of you and what you can do to prepare. This guide goes over everything that's involved in being an Open Source Comes to Campus mentor.
You may not be mentoring for the entire event. To make it easier to read this document, select what you've been asked to do below. If you don't know what parts of the event you'll be mentoring at, feel free to ask us for clarification, or just read everything. :)
If you'll be present for the Contributions Workshop in the afternoon, choose one of the following:
The general guidance section immediately below will appear for everyone, but you can toggle it on and off if you want:
General Guidance
Open Source Comes to Campus is very activity focused, which means that you'll frequently find yourself in the presence of a whole bunch of students attempting to join IRC for the first time, or understand a bug report, or use git, or fix a problem with a project. These students won't always ask for help when they need it, so it's important that you feel comfortable approaching and engaging them. This section has been written to help with that.
There are a few basic principles that should guide your interactions with attendees. We'll go over those first, and then we'll give you some practical advice.
Principles
Everything is a learning experience. We believe that there's always something to learn, for mentors as well as students. If you don't know the answer to an attendee's question, tell them so - and show them how to go about finding the answer. When a student gets stuck, don't just fix their problems for them - explain what the problem is and guide them through the solution. Open Source Comes to Campus is an ever-improving project, so when a student has a problem with the event itself or any of our activities or tools, encourage them to make an issue out of it.
Approach everyone. Every attendee should have at least a few good interactions with mentors at the event. (Unless the student clearly doesn't want to interact - see "Autonomy of Students" below.) While you should prioritize helping students who are struggling, it's also important to spend time with students who are thriving. It can also be hard to tell when a student is struggling, so approaching everyone means you won't miss helping those who tend not to ask for help.
Autonomy of students. We do our best to create a great workshop experience, but in the end it's every attendee's choice how much they want to engage. Don't pressure a student to do an activity they're not interested in or learn in a way they don't want to learn. (Some people learn best entirely on their own, and won't want your help no matter how badly they're stuck!) Do try to engage students, and offer them alternatives if they don't like an activity, but if that doesn't work, respect their decision and move on to helping another attendee.
Practical Advice
Signs Someone Is Struggling
- Facial expressions that read as frustrated, sad, angry, confused, bored, etc.
- Raised hand or other attempt to flag down a mentor.
- Looking around the room or generally not engaged with computer or handouts.
- The screen of their laptop does not display what it should, during a computer activity. Person is doing nothing with their hands, during a hands-on activity.
- The person is contesting the activity itself: "it's not useful", "it's not what I am here for". Refusal might be in fact a sign of struggling with the purpose and path of the activity.
Questions to Ask Students
If a student looks like they are struggling:
- How's it going?
- Where are you at in the exercise?
- Running into any snags?
- Would you mind telling me what you've done so far?
If a student does not look like they are struggling:
- How's it going?
- Where are you at in the exercise?
- What's your plan for the next step?
- How did you complete the last step?
- Can you explain {concept from the activity} to me?
During socializing periods (like lunch):
- How's it going? (Yes, this works for everything.)
- How'd you hear about the event? What made you want to come?
- What classes are you taking?/Have you picked a major yet?
- Do you use any open source projects?
- Are you interested in getting more involved? Do you have any hesitations? (This frequently leads to discussions about topics like finding the free time, finding good projects, etc.)
Common Problems
Assuming fault for failure.
The problem: When students have difficulty understanding an activity or contributing to a project, they often will assume it's due to their own ignorance/lack of experience/lack of ability. Because they're not as familiar with the obstacles open source presents, they can't identify what's going wrong - just that something is. They may assume it's entirely their fault and get discouraged.
The solution: Talk through the issue and reframe it as a lack of information, not a lack of ability. (Perhaps the project's guidelines aren't clear enough. Perhaps the student hasn't been taught a particular tool or concept yet.) Relate a story, if you have one, about your own difficulties doing a similar thing. Talk with the student about how they'd tackle a similar problem if they face it in the future./
Failing silently.
The problem: Students will sometimes run into issues with activities or with open source projects they're contributing to, and just quietly give up/move on to something else.
The solution: Emphasize the importance of feedback. Open source projects have elaborate systems set up to elicit, record, and respond to feedback: issue trackers, mailing lists, etc. Encourage students to use the Open Source Comes to Campus issue tracker where appropriate, and to give feedback to project maintainers via IRC, mailing lists, and issue trackers. If you have a story in which a bug report or more informal feedback helped you solve a problem, share it.
Having difficulty setting up a development environment.
The problem: Students can't complete an activity or contribute to a project because they're having trouble setting up the development environment.
The solution: This can be a tricky one for a mentor to address if they're not familiar with a given project's requirements. If you are familiar - or you're an old hand at debugging this sort of thing - great! Just make sure to show the student what you're doing and explain the steps you're taking. If you're not, you can role model lifelong learning by asking other people at the event (or on IRC) for help. There should be at least one person available at the event or on IRC who is especially good at handling environment setup, and you'll be told ahead of time who those people are.
Having difficulty finding a project.
The problem: Despite sincere interest in open source, students frequently will have difficulty choosing a specific project to work on. This is common enough that we've actually redesigned our curriculum to make it less of an issue.
The solution: You can see the Contributions Workshop section for more details about guiding students through their first contributions. More generally, though, approaches to finding good projects include asking:
- Are there any open source projects you already use?
- Do you have any friends or connections to an open source project?
- What kind of contributions do you want to make? (If programming, what language(s)?)
Coming into the event late.
The problem: If they're late, they're probably behind.
The solution: Talk with them briefly about what they already know. (They may not need to catch up on git, for instance, if they've used it before.) If they need to catch up on one or more skills, direct them to this page, which contains the contents of a typical Open Source Comes to Campus event written for a student to guide themselves through. Direct the student to that page and periodically check up with them. If possible, get them started with IRC right away so that they can ask questions into chat.
Please avoid...
Assuming attendees know what you know. Don't assume that an attendee knows something, no matter how commonplace or obvious it seems to you. For example, I used to open up documents in nano (my command line editor of choice) without explaining what I was doing. This confused a significant number of people - frequently people who were familiar with the command line and/or text editors, but had never heard of nano. Finally one of them asked me what was going on. Now I explain the first time I use a command line text editor to open a file.
Behaving surprised when a student doesn't know something. Relatedly, even if a tool or concept seems fundamental to you, don't show surprise or make a big deal out of it when a student hasn't heard of it. Our attendees come from all backgrounds, including non-CS ones. And regardless of background, everyone has a first time they hear about something. Make that experience affirming and enjoyable, not embarrassing.
Grabbing the keyboard. If at all possible, walk someone through their problem verbally. If you really need to type to figure something out, ask first and be careful to not be invasive about the other person's physical space if they do give permission.
Tutorial Presenter
If you're presenting a tutorial, make sure to talk to both the local organizers and Shauna, the main OpenHatch organizer, to go over what you'll be presenting. Our wiki documents our entire curriculum and most tutorials have a complete walkthrough. Some sections also have screencasts or video of someone leading the tutorial, plus a transcript. Slides and materials for various activities can be found in the github repository.
You are welcome to adapt and personalize the materials you'll be presenting.
If you'd like to practice presenting or be trained to lead an activity, just ask!
Git Activity Lead
A central part of our tutorial is teaching students to use git, specifically via Github. To do this, we've created an activity where students make changes to a toy project. You'll be leading a small group (typically between 3-6) students through the steps listed here.
Please take a look at the topics covered by the lesson and make sure you feel comfortable with them. If you're not comfortable with them, let the organizers know. We can help you get comfortable, or have someone else take your place, depending on what you prefer. If you would like to lead the activity, please give the organizers your Github username so we can give you admin privileges for your toy project repository.
There are typically a handful of students at any given event who are already familiar with git. If you feel very comfortable teaching git, you can lead these students through more advanced material. Please let us know if you'd like to be an advanced git mentor.
When leading the Git Activity, we recommend:
- Explaining the concepts behind git commands, not just using them. Common questions include "What's the difference between fork and clone?" and "Why do you have to do git add?"
- Visually as well as verbally demonstrating. Show students your computer screen as you lead them through the activity.
- Checking that all of your students have completed each step before you move on.
Career Panelist
Most events have a career panel where students can ask questions about mentors' experiences in open source. If you have, or have ever had, an open source job, you can be on the panel. There's zero preparation you need to do, but if you'd like to see how we structure the panel or some of the questions you might be asked, you can do so here.
The Contributions Workshop
The contributions workshop is the last part of the day. Over time, we've come to believe that the most important thing we can do for students is to help them build an ongoing relationship with an open source project - not simply fix a bug or land a patch. (Though it's awesome when they do!) Accordingly, we're working to identify great projects for beginners with clear documentation, enthusiastic maintainers, and a bunch of approachable tasks. The contributions workshop introduces students to those projects.
Overview of Workshop
Before the event, we'll identify and prepare open source projects for students to work on. (More on that below.) At the beginning of projects times, one of the organizers will go over the structure of this part of the day. Briefly, that structure is:
- Project Introductions: Project leads, both local and remote, will spend 2-5 minutes giving a brief overview of their projects and what tasks are available to work on. Remote mentors will talk via video chat. Paired mentors paired with a remote mentor will introduce themselves as the in-person mentor helping with that project.
- Contributing: The bulk of the workshop will consist of students working with mentors to contribute to a project. Depending on the schedule, this part of the day can be as short as an hour or as long as four hours. Most students will be working on a specific project from the Project Introductions, but there are other options for them. This is mostly something for floating mentors to pay attention to.
- Check In: Depending on the schedule of the event, organizers will conduct one or more check-ins where mentors and students talk about what they're working on, and if they're stuck.
- Wrap Up: This is a lot like a check in, but at the very end of the day. It marks the end of the contributions workshop, although it may be possible for students and mentors to keep working (ask the organizers).
Project Lead
Project leads are mentors who have an open source project they maintain or contribute to that they are interested in working on with students. If you're interested in being a project lead, please contact the organizers. Project leads can be in person or remote. Remote project leads will be paired with a paired mentor who can be their "eyes and ears" at the event.
Ideally all projects will fit the criteria of an OpenHatch-affiliated Project. That is, they will have good documentation, a tested installation and contribution guide, and bitesized tasks defined ahead of the event. All remotely-led projects will have this. For in-person mentors, there is more flexibility. Talk to the OpenHatch organizers about what you need to do to include your project. A common option is to work with students to improve your documentation and installation process.
We like to introduce students to projects before the event, so that those who are interested can get a head start on installing the project and learning about it. Your organizers will ask if you're willing to field questions and requests for help in the two weeks leading up to the event. If you are, we'll include info on your project and how to contact you in an email to students who have signed up.
Your responsibilities:
- Before the event (if remote): Help your paired mentor test out your project
- Before the event (optional): Help students get familiar with your project (cc your paired mentor on conversations)
- At the start of the workshop, give a 2-5 minute presenation on the project
- Be available for the duration of the workshop, whether via IRC or in person
- After the event, give feedback on and/or merge any pull requests/patches
Paired Mentor
A paired mentor is someone who is working with a remote project lead to help students contribute to a project. The paired mentor is the remote mentor's "eyes and ears" on the ground. They're able to see students as they work, and will be better able to notice signs of frustration, disengagement, or confusion. The two mentors should be comfortable enough with each other that the local mentor can easily say, "Why don't you ask [remote mentor] about that in IRC?" or "Why don't you ask [paired mentor] to show you that on your computer?"
Your responsibilities:
- Before the event: Read through the project's materials and install it on your computer
- Before the event (optional): Your project lead may be helping students prepare before the event. If so, they'll cc you. If you want, you can read and respond to conversations between project lead and students
- At the start of the workshop, introduce yourself when the project lead presents their project
- During the workshop, help students contribute to the project. Keep an eye out for signs of frustration. Keep in contact with your project lead on IRC. Make sure that you're keeping track of IRC handles so that project leads can follow up with students via email/github.
Floating Mentor
Floating mentors are not assigned to a specific project. As a floating mentor, you can help others lead a project if there are a lot of students or work with late arrivals and/or students who are struggling with the tutorial materials. If there are students who don't want to work on any of the presented projects, you can help them find a project by going through the Finding a Project activity. Or, if they have a project they want to work on, you can help them get started. Or maybe you'll find yourself in a deep, hour-long conversation with a student about open source. That's cool too.