On Saturday, June 22nd we ran our tenth Open Source Comes to Campus event, at Northeastern University. Many thanks to Ali Ukani and the Northeastern University ACM for hosting.

Staff

Shauna Gordon-McKeon, Ingrid Cheung, Paul Tagliamonte, and Brendan McLoughlin; plus student staffers Molly White, Alice Young, Spencer Florence, Richard Van Buren, and Jonathan Goodwin.

Selected Contributions

• One student fixed a bug in NLTK where a failure to test all cases had led to a divide by zero error. The student figured out which case was missing and added a line of code to the problem function to fix it. Her patch was accepted a few days later.
• Two students worked together on a “stale” pull request in PsychoPy. They weren’t able to address the main problem, which involved vectorizing code, but they went through the process of refreshing the patch, and also learned how to use several different merge tools along the way. Another student working on PsychoPy cleaned up the imports in two different files. Both changes were merged into the project.
• One student confirmed a bug in multiple versions and updated the issue to share that information.
• A student working on K-9 mail was able to reproduce and clarify a problem with opening .apk files in the application. Another student attempted to address a different bug in K-9, an off-by-one error in folder selection, but ended up focusing on getting the Android development environment set up properly.
• One student addressed an issue with Wikimedia’s Bugzilla configuration where an error in the .css file was causing a random bullet point image to show on various pages. She fixed the code and submitted a patch, which was later accepted.

Errata

• Thanks to our our Northeastern hosts, who opened their doors to area students, we had sign ups from almost a dozen additional schools, including: Boston University, UMass Boston, Wellesley, Harvard, MIT, Brandeis, Babson, Mt Holyoke, Colby and even students from CSU-Sacramento and Valencia College in Florida.
• We mixed the career panel up this time, and included more discussion about part time and temporary paid opportunities. We had participants from Code for America, Hacker School, and Google Summer of Code (a student, and a mentor) talk about their experiences. We also asked a few new questions that seemed to really spark discussion, including: what are the financial models of the companies you’ve worked for and the projects you’ve worked for?  What was a time you were hesitant or frustrated about something in open source?  What projects would you especially recommend to newcomers? The panel seemed more lively than usual, and attendees more engaged.
• I don’t think we will ever stop learning things about event planning. Added to the checklist this time: make sure the room you’re in has heat in the winter and air conditioning in the summer. We sweated our way through the day.
• There was a brief conversation among the staff about modeling confusion, ignorance, and failure. The git demo, usually one of the smoothest and most enjoyable parts of the day, included an extra 5-10 minutes of rebasing and apologizing because the instructor had forgotten to tell students to start a new branch before making changes. I thought it was great! We believe it’s helpful for students to see instructors mess up, try again, and succeed. In a conversation shortly after, when a student expressed frustration with git, I was able to say, “It’s a hard skill to learn. You saw [the instructor] – even he doesn’t have it mastered yet!”
• During this event, we introduced pen-and-paper bug report worksheets (available in our resources). Our goals were multifold. First, we thought that listing out the steps for fixing a bug would help students walk through them. Some students express disappointment if they don’t make it all the way to submitting a patch, but this method highlights the steps they do achieve. Second, it provides staff with a visual clue as to who needs help and who doesn’t. A student with a blank form and no steps checked off is more likely to be struggling than one who’s writing away. And third, it lets us as organizers determine what kind of bugs are working for students and where they’re running into problems. As we continue our efforts to curate the best first contributions for students, that information is invaluable.