Introducing CS students to open source
•Download as PPTX, PDF•
0 likes•29 views
Presented by: Ellen Spertus, Mills College Presented at All Things Open 2020 Abstract: Open source programming is professionally and personally rewarding, but many people are intimidated by the barriers to entry and the field's reputation for hostility to newcomers, especially members of marginalized groups. As a computer science professor at a minority-serving women's college, I have countered this by guiding students, as part of their required coursework, to learn and apply the necessary skills to make contributions to open source projects. I will share what I have learned over the years about breaking down the barriers to help other educators, mentors, and open source practitioners increase participation.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Introducing CS students to open source
Similar to Introducing CS students to open source (20)
More from All Things Open
More from All Things Open (20)
Recently uploaded
Recently uploaded (20)
Introducing CS students to open source
- 1. Introducing CS students to open source ELLEN SPERTUS MILLS COLLEGE OCTOBER 19, 2020
- 7. Git and GitHub Canonical repository Class repository Individual repository Local repository Clone Push Pull Fork Pull request Fork Pull request
- 8. Communication communication and community posting complete and useful information respectful communication
- 12. Selecting an issue Look at labels, such as “good first issue” or “beginner friendly”. Don't choose high- priority issues. Some issues are invalid. Discuss with maintainers before starting. Claim the issue if you want to work on it. Be prepared to start over with a new issue.
- 14. Useful techniques teams of 2-3 students per issue weekly meetings of 1-2 hours Slack server Help drafting messages
- 15. Getting a handle on large codebases
- 16. Projects
- 17. 2012
- 18. 2014 Trevor Adams Most homework assignments in CS classes either start from scratch or build on top of straightforward code and require relatively simple interactions with an existing API. In contrast, App Inventor was an ongoing project with • many contributors • a sizable codebase • elements that were deprecated • elements that were in progress, and • elements that hooked into other codebases. It was the first time I really had to understand and work with a large amount of code written by someone other than myself, figuring which parts I needed to deal with and how they worked, and just as importantly, figuring out which parts I could safely ignore. These are skills that are crucial for working on real software development projects, and it made me a lot more comfortable when I had my first industry experience and was faced with the same situation. Knowing that I could understand and successfully modify real, deployed code gave me a lot of confidence in myself as a programmer. 2012
- 19. 2014 Colin Lockard University of Washington PhD candidate Working on App Inventor was also my first experience using a real build system, with complex dependencies that didn't always compile correctly. In fact, if I recall correctly, my first week or so on that project was largely spent on Stack Overflow trying to resolve some issue related to competing C compilers. Not the most exciting work, but very educational. When I later went off to NASA for an internship, I arrived to find a group of other interns struggling with build problems and I felt like a superhero when I was able to immediately help them make progress. 2014
- 21. 2019
- 23. Conclusions
- 24. Benefits Working with production codebases and toolsWorking Learning how to communicate online in professional settingsLearning Solving real-world problems with actual usersSolving Feeling like real developersFeeling Having support throughout the processHaving
- 25. Challenges Faculty time requirements Students who feel like they don't belong on a team Students who need more structure Unpleasant surprises
- 26. Key points to communicate to students Participating in open source makes you part of a large and important movement. Even a small contribution is a big deal – and may take all semester. You can still be successful even if your PR can't be merged. Most people will be helpful and welcoming. You're not on your own.
Editor's Notes
- I teach at Mills College a minority-serving women's college (with coed grad programs) in the San Francisco Bay Area. Our students, like me, tend to be idealistic and want to make the world a better place. This is one of the reasons open source appeals to them.
- Unique graduate program for students with a bachelor's degree in another field who want to transition into CS. Like all of Mills' Many of our classes are dual-level, and I need to provide additional material to graduate students. In programming project classes, I've been having the grad students contribute to open source projects.
- I'll now say a little about skills and tools that students need.
- It’s rare for students to have experience with the command line, so I have them work through tutorials. I have Windows users install Git for Windows, which includes Git BASH.
- Of course, students need to be able to use git and GitHub. The workflow I teach is a little different from the standard one.
- Students may be reluctant to communicate with strangers online, especially if they're concerned that they might face racism or sexism. I help them [CLICK] make their first post to Stack Overflow, [CLICK] communicate with developers on Discord, [CLICK] post to GitHub, and [CLICK] write proposals for complex changes. I solicited students’ experience when writing this talk. One said: One element of the class that I appreciated was a consideration of [CLICK] communication and community. As you encouraged me to write a StackOverflow post on my build problems, you also stressed the importance of good etiquette in [CLICK] posting complete and useful information to make things as easy as possible for any friendly person who would take time out of their day to answer. We also discussed the importance of [CLICK] respectful communication in open source projects. I try to keep these lessons in mind today when I communicate with my collaborators. "
- The impostor syndrome is real and always present. You need to encourage students to have a growth mindset. It's not enough to mention it once. Every day, you should communicate to students that you make mistakes and that everyone feels overwhelmed a lot of the time. It doesn’t mean they don’t belong in the field; it means they’re working on hard problems.
- Tell students about your mistakes. I share with them an article that I wrote about mine. In the picture on the right, I’m wearing a t-shirt that says: “If people learn from their mistakes, I must have a Master’s Degree by now” and point out that I have a PhD. I’ve made even more mistakes! Throughout the semester, admit your mistakes, and reward students for finding and reporting them. A lot of professors
- At first, I had students work on App Inventor, because I helped create it and knew that my old colleagues would answer their questions and review their PRs. Now I let students choose projects. They should make sure there have been recent updates to the projects. If no code has been pushed in years, their changes are unlikely to be incorporated. I tell them to look for an active and friendly developer community. Often these are on Discord, and students can see how people are treated. They should look for a project that is welcoming to newcomers, as shown on their forums or contributor guidelines. Specifically, they should look whether pull requests get reviewed promptly. If not, their changes might languish.
- Choosing a project is usually easier than selecting an issue. I advise them to [CLICK} look at labels, such as “good first issue” or “beginner friendly” Don’t choose high-priority issues, which are likely to get fixed quickly by a more experienced developer. They should know that some issues they see, especially feature requests, made be considered invalid by the maintainers. They should discuss issues with maintainers to make sure they want someone working on the issue and Explicitly claim the issue. Above all else, they should be prepared to start over with a new issue if theirs gets fixed by someone else, made obsolete, or proves too difficult.
- Useful techniques for running the class: Have all of the students work on the same project, but have teams of 2-3 students per issue Have weekly meetings to make sure students stay on track and help them with anything they get stuck on Maintain a Slack server where students can ask you and each other questions and share information Always be willing to help students draft messages
- I sometimes find it useful to create UML static class diagrams. I’ve had students do this, although I’m not sure it’s been helpful. Have them step through the code in a debugger.
- Here are some of the projects students have worked on.
- In 2020, Kate Feeney and Trevor Adams made contributions to App Inventor. Kate went on to do the Google Summer of Code.
- Trevor wrote about the experience…
- I had students work on App Inventor again in 2014. Here's what Colin Lockard, now finishing his PhD as University of Washington, wrote.
- In 2016, Kate Manning and Emily Kager added an extension to App Inventor. Both went on to work for [CLICK] Mozilla, Kate through Outreachy, Emily as an intern and then full-time employee.
- In 2019, students choose to contribute to an app some of them use, Habitica.
- This fall I’m teaching a Java development course. This is my first time supervising open source in a non-Android environment. I wasn’t able to find many active projects except for [CLICK] Minecraft, which students are thrilled to work on. They chose to contribute to [CLICK] EssentialsX, one of the most popular plugins.
- support: both technical and psychological
- There may be unpleasant surprises, even more than with regular assignments that you create. This requires a lot of faculty time. I’ve worked with 2-8 students at a time. I don’t know if it can be scaled to large courses. There have been problems with students who don’t feel like they belong on a team with other students because of their own demographic differences. Even if the other teammates don’t discriminate (which can be hard for an outside professor to determine), students’ reasonable fear of discrimination can get in the way. Some students, even graduate students, need more structure and drop the course or avoid doing the work.