1. Mentorship Models in Open Source Software Development Courses Chris Murphy University of Pennsylvania POSSE Roundup – SIGCSE 2016

2. Overview UPenn has offered an undergrad Open Source Software Development course since Spring ’14 Professional software engineers act as mentors to help students make contributions We have tried four different “models” of mentoring Mentor’s role in the community and plan for the project affect student satisfaction! Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016

3. Background: Facebook Open Academy UPenn participated in Facebook Open Academy in Spring ‘14, Fall ‘14, and Spring ’15 Organized by Jay Borenstein from Stanford Univ. Around 10-20 participating universities each semester Students contribute to OSS projects under supervision of a local faculty member and mentorship of professional software engineer Mentors on-board students during “Code Sprint” at Facebook HQ in Menlo Park Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016

5. Background: OSS Course at Penn More recently we have used Philadelphia-based mentors from Comcast and AGI and followed a model similar to Facebook Open Academy Code Sprint at Comcast HQ Ideally groups of two students, two mentors Weekly check-ins with mentors Weekly class meetings To date 40 students have participated in the four offerings of the course 29 projects, ~45 mentors Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016

6. Mentorship Models 1.Committer: mentor has commit access to the repo MongoDB, Prediction.io, Mozilla Firefox, Cesium… 2.Contributor: mentor is a regular (code) contributor Google Polymer, GIMP… 3.Advisor: mentor has no prior experience in OSS project but can help install, troubleshoot, etc. 4.None: student gets mentorship from community Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016

7. Evaluation RQ: “What effect does the type of mentor have on student satisfaction?” No quantitative results (sorry!) Qualitative feedback on mentors from final reports Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016

8. Committer/Contributors grease the skids Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016 “Because he is one of the project’s main contributors, he was able to accept pull requests which is what allowed us to move quickly and release code during the semester.” “He did more than just mentor us at times in the project, he was actually working actively to find answers. Rather than say ‘This is what you need to do next,’ he would be an active participant in getting it done.”

9. … but also need to have a plan! Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016 “More of an onboarding process would have been helpful. We only did a short tutorial, but it only included things I could’ve learned online easily. I wish they had gone through the code base and explained how it all fit together. I also wish they had some projects in place for us to work on.” “[The mentor should] try to provide a bit more guidance to what they would envision the project to turn out and the expectations set for the project. I didn’t really know what he expected or wanted.”

10. Having no mentor can work… if you try! Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016 “I would not recommend that students be allowed to choose their own, mentorless projects, as I think it is very hard to stay motivated and productive on a project like this without anyone going after you to do work.” “A mentor is most helpful if they have experience with or are affiliated with the project being developed … my prior experience in open source communities guided me through situations where a mentor might have otherwise assisted.”

11. Mentor/Advisor: blind leading the blind? Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016 “Our mentors tried to help as much as possible but there was only so much that they could do since they also had zero prior knowledge about the project.” “The weekly meetings weren’t very useful due to the fact that our mentors had no prior experience with the project.” “We made the mistake of choosing the project without really consulting the mentors … we should have tried to change to a different project early on to work on something that our mentors were more familiar with.”

12. Conclusions Mentorship allows the students to get more directly involved, and provides opportunity for support, encouragement, and feedback Regardless of role, mentors must be dedicated to students’ success and have a plan in mind However, a mentor with no previous experience – no matter how well-meaning and engaged – may ultimately have a negative effect Chris Murphy – University of Pennsylvania – POSSE Roundup – SIGCSE 2016

13. Mentorship Models in Open Source Software Development Courses Chris Murphy University of Pennsylvania cdmurphy@seas.upenn.edu http://www.seas.upenn.edu/~cdmurphy/foss