On Saturday, October 19th, we ran our sixteenth Open Source Comes to Campus event, at Columbia University. Thanks to Columbia University’s Women in Computer Science and the Application Development Initiative for hosting! Check out the gallery of the best photos from the event (and the other ones).
- Mentor Ivete describes her experience working with a handful of students: While browsing some projects using open government data, we noticed a bug in opencongress.com‘s member stats, where a few members had a rank that was higher than the total count of members, so that is clearly incorrect. We started by filing a bug in the Github repo’s issue tracker and then went looking at the calculation of that number. While we were working through that, we happened to read on opencongress.com‘s homepage that they are redoing the site and will launch a whole new site within the next month. We decided to stop trying to fix the bug since the fix would probably go unused, but left the ticket open so that the maintainers could be aware of it. And one of them commented on the bug the next day, confirming it!
- Several students worked on getting the NLTK development environment set up and on understanding some of the issues reported in the NLTK issue tracker.
- Another student looked at a feature request for Tomboy a desktop note-taking application. Unfortunately a slow internet connection meant he could not download the libraries needed to work on the project, but he was able to verify that the feature had not yet been added and located where in the project changes would need to be made.
- One student was very interested in the projects maintained by the Sunlight Foundation. He downloaded several repositories and browsed through the contents, then headed over to the OpenStates IRC channel where he worked with maintainers to updated issues in the bug tracker.
- We had 29 students attend this event. Students were very prompt – many of them even arrived before breakfast! – and most stayed throughout the day. Our process for getting latecomers caught up seems to be improving as well.
- Our last event, at Morris, had showed us the need to develop a more extensive git curriculum for more experienced attendees. Although we weren’t able to extend the curriculum in the short span of time between the two events, we made sure to group the more experienced students with our most git-savvy instructors. Special thanks to Ivete and rmo for leading students on an impromtu tour of advanced git. Feedback from Ivete, rmo, and their groups has helped us determine which topics to cover in the extended lesson.
- We recommended explainshell to students as a great resource for learning about the linux command line. This sparked a discussion about how the tool could be enhanced and what steps students might take to contribute, such as submitting a feature request or forking the project.
- We were excited to have Princeton’s Katherine Ye attending the event. Katherine was interested in organizing an Open Source Comes to Campus event at Princeton and wanted to see what it was like. Just one month later, the Princeton event was a reality! We’re always excited to have organizers attend our events and get a feel for what they’re like, so if you’re interested in running an event, let us know and we’ll make sure you’re invited to any in your area.
On Saturday, September 28th we ran our fifteenth Open Source Comes to Campus event, at the University of Minnesota at Morris. Thanks to the Computer Science Discipline for hosting! Check out the gallery of the best photos from the event (and the other ones).
Elena Machkasova, Nic McPhee, Kristin Lamberty, Jim Hall, Alex Jarvis, Dan Flies, Matt Hardy, Shauna Gordon-McKeon, Asheesh Laroia
- One of the cooler open source projects we’ve had for students to work on was Jim Hall’s Simple Senet. He worked with a student to give users the ability to tweak rule settings. Along the way they played some senet, which looked like a lot of fun.
- Another student looked at an old patch that had been submitted to SVG-edit and found one of the issues it addressed had already been fixed. She also found that it did not effect the other issue it addressed.
- One student reproduced a behavior in Firefox but questioned whether it was really a bug.
- Another student reproduced a bug in FBReaderJ.
- A group of students and mentors worked together to fix a bug in wordpress. That’s them above, still working on it after the event was technically over.
- We had a truly exceptional team of mentors for this event: the entire tenured Computer Science faculty at Morris (Elena, KK, and Nic); open source veteran Jim Hall; and a great group of alumni who were in Morris for homecoming weekend (Alex, Dan and Matt). Everyone knew someone else in the room – some people knew everyone else in the room! – and this level of ease and friendliness made for a great day. There was a lot of fun IRC chatter, the career panel was lively and ran long, and students seemed very comfortable asking for help.
- The above experience left us wondering: how can we promote this kind of atmosphere at events hosted in communities that are not quite as close knit? Ice-breaker and social activities may be just as important to success as any of our technical training.
- There was a small group of more experienced students who were already familiar with git, and were consequently pretty bored with the Practicing Git activity. This experience inspired us to expand the git lesson to include more advanced topics such as branching, merging, and multiple remotes. It also reinforced the importance of finding out about attendees’ experience levels ahead of time.
- Speaking of the Practicing Git activity, one of the groups produced the best website to date. For certain definitions of “best”.
- CS faculty member and host organizer Elena Machkasova introduced many of us to the concept of code poems with her poem written in Clojure.
- At the event, student Andrew Latterner announced the start of an Open Source Development Club. We wish Andrew good luck and great success!
Today, we’re releasing a handbook to help open source projects prepare themselves for events.
Here’s why: over the last year of Open Source Comes to Campus, we’ve given more than two hundred people the tools and the opportunity to contribute to open source projects. But not every student is able to submit a patch or pull request. The biggest obstacle by far? Confusing documentation and poorly defined tasks in the projects they’re trying to contribute to.
A group of students at our Purdue event faced this obstacle. They spent all afternoon trying to address a bug in Privly. Their description of the problems they encountered: “lots of downloads, need an approved account to have access… had to create own database on localhost… tears clouding vision”. Although they were good-humored about it (see the picture above), they never were able to work on the task they’d picked.
At OpenHatch events, we’ve adapted to this common roadblock by requiring that the projects we present to students do a few things, including testing their installation instructions, identifying good tasks to work on, and being available during some of our events. We call these OH-affiliated projects. Putting these benchmarks in place has helped us increase the number of contributions at events, and decrease the frustration. We’d recommend that any event organizer ask the same of participating projects – especially if their event is geared towards newcomers.
To help open source projects prepare themselves for events, we’ve written a handbook aimed at making projects easier to understand, install, and contribute to:
It’s a short, practical list of steps to you can take to improve the odds that newcomers will be able to contribute to your project at a hackathon, workshop or sprint. For each recommendation, we’ve included an example of implementation from our own project: OpenHatch.
The guide is, itself, an open source project (licensed CC BY). We welcome your feedback and contributions: you can share advice and submit changes via email, the issue tracker, or by submitting a pull request on Github. You can fork the guide as well.
We hope you find this helpful, and that it increases the number of successful contributions – and the number of happy contributors – to your project.
You can learn more about what OpenHatch has been working on (and support it with a donation) on our 2014 fundraising page.
A little less than a year ago, I was asked to direct OpenHatch‘s Open Source Comes to Campus event series. Open Source Comes to Campus is a workshop designed to introduce college students to open source, to teach them how to use tools like version control and issue trackers, and to guide them through making their first contributions. When I joined, OpenHatch was averaging two events a year. I was asked, hopefully, if I could run seven events in 2013.
The year did not begin auspiciously. I accidentally scheduled the first event for Presidents’ Day Weekend. We had less than a dozen people show up that snowy morning. Nevertheless, we had a lot of fun, and the day seemed like a success when one of our attendees, Jane, grinned widely and said: “Today has been very empowering for me regarding my computer and the ways I can manipulate it.” I scribbled it down on a napkin so I wouldn’t forget it.
Since then, we’ve run twelve more events, nearly doubling our goal from the start of the year. We’ve been to big cities like New York, San Francisco and Chicago, as well as small college towns like Wellesley, Amherst, Lafayette and Morris, Minnesota. We’ve taught hundreds of students, and thanks to the generosity of our hosts at Northeastern, UMass-Amherst, CCSF, and UIC, who opened their door to students from other local schools, we’ve been able to reach students we would have missed otherwise. We’ve met some amazing people, gotten some thought–provoking questions, and seen some… interesting creations. Through trial and error we’ve been able to make some big improvements to our process and our curriculum. It’s been a great year.
But for every event we’ve successfully run, there’s been another we couldn’t get to. Aside from one part-time staff member (me), OpenHatch is made up of volunteers. We don’t have the time or the money to run events in all of the places we’ve been asked to run them, whether that’s in faraway places like Alaska, India or Australia, or closer to home.
Scaling our events
Our solution? Open Source Comes to Campus In a Box. We’re carefully documenting every part of our events, from the materials we present to the way we build our publicity websites, from food and space checklists to templates of all the emails we send. Our hope is that local organizers will be able to use our materials to run their own events, as has happened with our Python Workshops.
We’ve already had one success story. In late November, an enthusiastic group of students from Princeton’s Women in Computer Science pulled off a great event with over thirty attendees, the first accomplishment of their newly-created open source club. They’ve given us some valuable feedback about how to improve both our events and how we document them. We’re excited to keep going! Boston University will be running a similar event in the spring, and we’re looking for more schools who are interested.
Our efforts to improve and scale Open Source Comes to Campus have paid off in other ways as well. Because our materials are now online, we can tell students who will be arriving late to check out a lecture or activity ahead of time. We can also use the activities on their own at other events: I gave our open source communications tools presentation at AdaCamp, and ran our hands-on git activity at BarCamp Boston. Thinking hard about how to improve the contributions workshop led to a (still in beta) guide for open source projects on how to become more accessible. It also led to a carefully curated set of first tasks, supplied by OpenHatch-affiliated projects. These tasks are ideal for attendees at our events, as well as for newcomers who reach out to us online.
We’re always looking for help with Open Source Comes to Campus. How can you get involved? If you’re affiliated with a college or university, you can host an event. If you’re an open source aficionado who’d like to volunteer as a mentor, you can sign up to be notified when there’s an event in your area. If you have an open source project you’d like to welcome newcomers to, you can become an OpenHatch affiliated project. You can help us with the issues in our issue tracker, give us feedback on our materials, and you can always, always join us on IRC.
If you’re financially able, you can donate to support us, too. Your contributions, sponsorships from companies like Puppet Labs, Github and Google, and the effort of dozens of volunteers have made it possible for us to reach more than 200 students this year.
On Wednesday, September 25th and Thursday, September 26th we ran our fourteenth Open Source Comes to Campus event, at the University of Illinois at Chicago (UIC). Thanks to Women in Computer Science at UIC for hosting! Check out the gallery of the best photos from the event (and the other ones).
- This was our first two-day event, and the different structure really changed the event. It emphasized for us the importance of getting our teaching materials online and in great shape. It was very helpful to be able to point attendees to, for instance, the Git training mission as a way to catch up on what they missed the day before. It would have been even better if we could point those who only came the first day to resources for what they were missing the next day. Since this event, we’ve put many of our materials online.
- Because many attendees could only make one night, there was a great deal of duplicated material. Projects time was much shorter than usual, and almost all of the attendees chose to work on a single project: my effort to digitize the 1870s radical feminist magazine, Woodhull and Claflin’s Weekly (read more on Wikipedia). A number of attendees did transcription while others helped with documentation and helped me brainstorm better ways to organize the project.
- Our career panel was part-local, part-remote, with Chicago-area mentor Beth Lynn Eicher in person and Sumana Harihareswara and Marina Zhurakhinskaya joining by video conference. This is the second time we’ve had remote participants in a career panel, and the second time it’s gone off pretty flawlessly. Previously we’ve invited remote participants only as a backup when our mentors haven’t been interested in doing the career panel, but there’s something to be said for the diversity of experiences you get when you can draw from anywhere. We tried to record the career panel, and got as far as setting up a Google Hangouts On Air, but forgot to hit the record button!
- Thanks to WiCS/UIC’s generosity in opening up the event to all women students, we had sign ups from thirteen different area schools, including Chicago State, University of Chicago, Loyola, Robert Morris, DePaul, DeVry, Dominican University, Northeastern Illinois University, and of course, UIC.
- This was our first explicitly women only event. (Although one previous event, held at Wellesley College, had all women attendees due to the student body.) This created an interesting and enjoyable dynamic. Several times during the two evenings spontaneous discussions emerged about the obstacles involved in being a woman in technology.
As always, our Open Source Comes to Campus events are possible thanks to our sponsors. Special thanks to Puppet Labs for their Bronze sponsorship, and to GitHub for funding food.
- A pair of students were interested in tackling bugs in Octave, a language for data manipulation, computation and visualization. Setting up a development environment in Windows, which both of the students were using, proved difficult – so they focused instead on setting up linux virtual machines on their computers.
- One advanced attendee, who had previously worked on BioPython, dived into the project and looked at two different bugs. She improved project documentation and contributed to a discussion about how to implement a new feature. She also contributed to MediaGoblin by creating a patch for a configuration error.
- When people picture themselves contributing to open source projects, they don’t usually see themselves testing other people’s patches, but it’s a very useful contribution. One student confirmed that a patch worked and contributed to an ongoing discussion about what the final fix should be.
- Another attendee found that a bug in svg-edit had been fixed but not released, so that users were still having trouble. He left a comment to this effect.
- One student worked remotely with a maintainer of PsychoPy to set up the development environment and become more familiar with the project.
- A group of students tried to fix what seemed like a straightforward bug in Privly but had a lot of difficulty getting the development environment set up. See the ‘Errata’ section for more on this.
- You can see the group who worked on the Privly bug in the photo at the top of the page. Their description of the issues they encountered: “lots of downloads, need an approved account to have access… had to create own database on localhost… tears clouding vision”. While they still had a great time, this experience made it clear to us that we need to do a much better job of picking projects to work on, and make sure that we’ve vetted the development environment setup process thoroughly. Since the Purdue event we’ve focused on having a smaller number of high quality/highly prepped projects, and we think it’s showing major benefits.
- We had 25 attendees at the event, many of whom were non-CS majors thanks to our efforts to improve outreach to science majors. Part of that effort involves identifying and publicizing to potential attendees the many amazing open source science projects out there. You can help us with that.
- We introduced two major changes to our curriculum at this event:
- A ‘Bug Comprehension’ activity where students pair up and read the issue tracker threads for two delightfully strange bugs: a problem with the Android calendar where the month of December was missing and a bug where Open Office doesn’t print on Tuesdays.
- ‘Practicing Git’, a hands-on group activity where students practice forking and cloning repositories, making changes, and submitting pull requests by changing a toy project. You can see our student handout for the project and one of the repositories students worked on.
We hope to have longer posts up soon which will elaborate on these curriculum changes and why we made them.
- To continue the trend of ‘recommended reading lists’ a few mentors and students got into a discussion on good readings for women in technology and science:
- And to continue another trend: the phrase of this event was “rubber ducking” – the practice of asking your questions to a rubber duck or other inanimate object in the hopes that the process of clearly defining your question will help you answer it.
At each Open Source Comes to Campus event, participants ask unique, thought-provoking questions. We decided to write down these questions and answer them more fully on our blog. If you have any additional suggestions or advice, please add them in the comments!
These questions are from our IU Bloomington event. This post was co-written with Asheesh Laroia, with contributions by Karen Rustad and Máirín Duffy.
Read on to learn more about building open source communities, diff and patch, open source design, and part-open/part-closed projects.
I’m worried that I’ll be a burden on a project because I’m so new. What kind of effort does a project have to make to build an open source community?
First of all, you should know that expert open source community builders like Linus Torvalds understand this tension between training new contributors and the time it takes from existing maintainers to mentor them. I’ll quote two paragraphs from a 2004 post Linus made on the Linux kernel list:
On Tue, 21 Dec 2004, Jesper Juhl wrote:
> Should I just stop attemting to make these trivial cleanups/fixes/whatever
> patches? are they more noice than gain? am I being a pain to more skilled
> people on lkml or can you all live with my, sometimes quite ignorant,
> I do try to learn from the feedback I get, and I like to think that my
> patches are gradually getting a bit better, but if I’m more of a bother
> than a help I might as well stop.
To me, the biggest thing with small patches is not necessarily the patch
itself. I think that much more important than the patch is the fact that
people get used to the notion that they can change the kernel – not just
on an intellectual level (“I understand that the GPL means that I have the
right to change my kernel”), but on a more practical level (“Hey, I did that small change”).
Another thing to keep in mind that is, for most projects, the project leader is the only contributor (source). Consider this — the act of “bugging” them with questions as a newcomer can make them more enthusiastic about the project as a whole!
If it were trivial to build an easily accessible open source community, virtually all projects would do it. There is some effort involved. Of course, a lot of the work which makes a project welcoming to newcomers – good documentation and setup guides, a well-maintained issue tracker, active development, standards of conduct in the community – makes the project better for everybody. But it does take time and energy, which many projects aren’t willing to expend. That’s why we exist! We know that some projects put more effort into welcoming contributors, and we want to help you find those projects.
The kinds of projects that welcome newcomers don’t see you as a burden. They see you as a huge help – even when you’re struggling to understand bugs in the issue tracker or get the development environment set up. When you ask a member of an open source project for help, that gives them important information about what part of their project is confusing or incorrect. The questions you ask and guidance you need lets them know how help others later on. And of course, once you’ve gotten familiar with the project, you’ll be able to help even more. The right kinds of project see that potential in you and want to work with you to get there.
Two rules of thumb for people who worry about being too much of a bother (which includes us, sometimes!): First, if people on the mailing list or the bug tracker haven’t told you to stop talking, then you’re probably okay, even if they haven’t replied to you yet. Second, if you want another opinion, just join the #openhatch IRC channel and ask us.
What are the flags for the patch and diff commands? Why would you want to use them?
The quick answer is, “You always want diff -u, and you usually want patch -p1.”
The long answer is: The diff tool generates a text file summarizing the changes between some files. There a variety of formats that diff knows how to generate, and the default is an older format that isn’t widely used anymore. The most commonly used change format is “unified diff,” which is what “-u” specifies. My favorite (in its weirdness) is the “Ed script” format; you can read about that on Wikipedia.
As for patch, the most common command line flag to change is the number after “-p”. This helps patch choose which files on your computer to edit. Recall that the idea of diff+patch is that one person creates a file using the diff tool, and another person applies it on their computer with patch. In that case, what if the person creating the diff had placed the files in a different directory than you? Your use of the “-p” parameter controls that, and the “Levels in the Patch Command” section in How to create and use a patch in Linux explains more. Not everyone is excited about having to choose the right option; you can read Dustin Kirkland’s blog post where he wrote a tool to avoid having to ever pass this parameter in!
Like most UNIXy utilities, diff and patch have pages in the “manual”, which you can access by running man diff or man patch in your terminal. You can also read these online, for example at man.he.net.
How can I help open source projects with design? Would I look in the bug tracker?
answer written by Máirín Duffy and Karen Rustad
You rarely find purely-design issues in bug trackers. Often you find a feature request which has an obvious design component, but the design and the development are lumped together in the same ticket. One approach, then, would be to make a new ticket for just the design, link it to the original ticket, and then assign that to yourself, which both communicates your intent and breaks the feature request up into more manageable chunks of work. But you may be better off looking specifically for projects that have design teams, as sometimes the design teams have ticket trackers with easy tickets designers can pick off, or a specific process for getting started as a designer.
It’s important to note the difference between a visual designer/artist and a UX designer/usability practitioner. Visual designers/artists usually find it easier to get involved – most projects need icons, logos, marketing materials or other artwork at some point. I [Karen] have had the best success just asking a project maintainer in IRC what design needs they have, or pointing out a design problem I’ve noticed and expressing an interest in fixing it, and chatting from there.
It’s harder to get involved as a UX designer or usability practitioner. Design is ‘controversial.’ (See the GNOME 3 design.) You always want the developers to have your back so it’s very important to cultivate a great relationship with them and be very willing to move on to another project if a project you’re interested in turns out not to be so interested in having a UX designer or usability person involved. The best luck I [Máirín] have had getting involved cold turkey, when I had no experience with the project or people involved, was to actually design something for them first, send it to them, and ask for feedback. If you get it wrong but it’s obvious from the work that you’ve got good chops then very likely they’ll start a healthy dialogue with you and bring you into the fold; but the risk is you never hear back and the work you put in doesn’t really go anywhere (into the upstream you intended it for at least).
What if you want to make only part of a project open source?
There are many reasons you might want to keep some parts of a project private. Maybe your project deals with sensitive information and you currently store that private data alongside your code. Maybe you’re a teacher and you don’t want students getting access to materials they’ll be tested on. Maybe you’re a company and financial success means waiting to make all of your work open source. Maybe you’d like to wait until your work is more polished before you show it to the world (though this is a common trap that leads people to forget to ever share!).
Whatever your reason, generally the best way to proceed is to separate the open and private parts of the project into different repositories. There are several hosts that support both open and private repositories. Some, such as Bitbucket, provide private repos for free (although only for five users or less), while others such as Github charge for them (although Github is currently providing private repositories for free to women through the Ada Initiative, and also a standing offer for students). If the sensitive information is relatively limited, you may be able to keep it in a single file or folder outside of the version controlled repository where it is easily referenced.
If you need to keep information private for legal reasons, it’s important that you consult with whoever put those rules into place to make sure your chosen solution adequately protects the information.
You can read more about a part-open, part-closed strategy from people who have done it. “Open Source (Almost) Everything” is a seminal post on the topic, by Tom Preston-Warner, one of the founders of GitHub; you can also read posts decrying this “open core” model.
For Ada Lovelace Day this year, we decided to profile some of the women who have helped us organize and run our Open Source Comes to Campus events. The five women below are just a few of the dozens of amazing hosts and mentors we’ve had the honor of working with.
Kristian invited OpenHatch to Wellesley College after hearing about us from Sumana Harihareswara, who gave a talk at Wellesley about women in open source last year. She understood that open source sometimes has a steep learning curve and hoped that OpenHatch could help guide her and her fellow students through the first steps of that process. Kristian, who also revived the Computer Science Club on her campus, is a great organizer and helped us get the event smoothly before settling down to take everything in as a student. By the end of the day she had submitted a patch to the official Python documentation, which was accepted a few days later.
Kristian began programming during an introductory class her freshman year, and fell in love with it immediately. According to Kristian, “Open source came into the picture after realizing that I’m utilizing all these languages and technologies for free and wanted to give back.” She adds that it’s a great way to exercise computer science skills in a real world setting.
Kristian graduated from Wellesley last spring and joined Carbonite, Inc as an associate software engineer. She hopes to eventually co-found her own technology company and to help inspire women to support each other when navigating careers in technology.
Molly was one of the main hosts/organizers for our event at Northeastern University this summer. Because the event was open to all students, Molly helped bring open source not just to NEU but to people from a dozen different schools. In addition to organizing the event, Molly helped as a mentor during the event and joined our career panel to talk about her experiences doing Google Summer of Code.
Molly first got involved with open source at the age of 13, when she began editing Wikipedia. She started programming in late high school, and taking classes at NEU confirmed her interest in computer science. Naturally, her first open source contributions were to MediaWiki, the backend of Wikipedia, with whom she did Google Summer of Code. Her advice to women getting started with open source? “Don’t be afraid to ask for help. I was really shy about this when I first started programming and contributing patches, but I’ve had almost entirely positive experiences when I ask for help. I usually get really useful answers, and very rarely feel like people are judging me negatively for not knowing exactly how to do something.”
Molly continues as a student at Northeastern and as a volunteer contributor to MediaWiki. She’s also a research assistant with the Lazer Lab at Northeastern on a project to use data from Wikipedia and other sources for election prediction.
Mel was one of the mentors for our recent Open Source Comes to Campus event at Purdue University. This was hardly Mel’s first open source rodeo: she’s a PhD student in Engineering Education at Purdue, a two-time resident at Hacker School, and used to teach professors how to help their students get involved in open source. That experience made her an excellent mentor not just to the students at the event, but to us. Mel provided great feedback after the event, and helped us think through our goals and teaching methods. We put her advice – and a new activity which she brainstormed with us – into action immediately.
She describes her own start in open source: “I started by staring at my computer going ‘wow, Open Source is so cool. I wish I could contribute to it. But I’m not Good Enough yet. I’d better go study more… then I might be Good Enough to help out.’ 6 years and an engineering degree later, I realized this was an endless loop; there was no breakpoint criteria for ‘good enough’, so it would always be ‘better than I am right now, I’d better go and study more.’ At some point, there had to be a beginning, as messy and/or awkward as it might be.”
Mel recommends finding a mentor to help you get started in open source – someone who’s willing to “meet you where you’re at and get you to the point where you feel comfortable contributing independently.” She believes that for most people, the community around a project is more important than the project itself, when you’re getting started.
Devina was one of the lead organizers for our women-only event in Chicago last month. Along with several other members of the University of Illinois-Chicago Women in Computer Science (our hosts), student leaders at other schools, and women active in the Chicago open source community, she helped us pull off an amazing two-night event. An experienced open source programmer, she helped out as a mentor and helped students from across the Chicago area feel welcome at the UIC event.
Devina was introduced to open source when she was 12 and her father brought home a Linux machine. “It was amazing, the machine ran way faster than my emachines, so I used that all the time. Obviously all my teachers scolded me for not turning in a MS Word formatted document (so what else is new). The big push I had in my life for technology was my dad, he really guided me into a field he knew I would be perfect for.”
Devina continues to organize with WiCS. For Ada Lovelace Day, she helped organize and is on a panel about about the Grace Hopper Celebration of Women in Computing (an event where we had the pleasure of seeing her again.) She’s also planning her first steps towards a longtime dream of hers: building her own operating system. We suspect she’ll be a success at whatever she puts her mind to, whether that’s putting together operating systems – or communities.
Elena is perhaps the single biggest reason for our recent whirlwind tour, in which we visited three states, held five events, and reached over a hundred students from dozens of different schools. Elena first heard about us at a Clojure meetup in Boston, and immediately contacted us, asking us to come to the small, public liberal arts college in Morris, Minnesota where she is a professor of Computer Science. Over a year later, we finally made it out (stopping in Indiana and Illinois along the way.) Thanks to the enthusiasm of Elena and other faculty and students, the Morris event was one of the smoothest, friendliest, most productive events we’ve had.
Elena has three pieces of advice for students entering open source: “Build upon what you are good at and what you are interested in, and don’t be shy about contributing what you are good at. Don’t avoid tasks that look scary or confusing, try them. If it doesn’t work at first, ask someone for help. Don’t get frustrated, new skills take time to develop. And keep on learning: from sources, courses, mentors, etc. This field is developing incredibly fast, and it’s fascinating!”
Elena and her fellow faculty at Morris plan on keeping open source a part of their students’ education, both by running Open Source Comes to Campus-style events in the future and by incorporating open source into their curriculum. Elena also incorporates open source into her poetry – such as this poem written in Clojure.
Thanks so much to Kristian, Molly, Mel, Devina and Elena for agreeing to be profiled in this post. Thanks also to the many other women who have participated in Open Source Comes to Campus over the last year as volunteers, organizers, mentors, and attendees. One of the best things about working with OpenHatch has been getting to know so many brilliant, friendly, giving women in tech, and I hope to keep meeting you all, online and off.
Happy Ada Lovelace Day, everyone!
On Saturday, September 21st we ran our twelfth Open Source Comes to Campus event, at Indiana University – Bloomington. Our thank yous to Dr. Lamara Warren and Lindsey Kuper of the School of Informatics and Computing for hosting! Check out the photo gallery and out-takes.
We had several students attempt to work on PsychoPy, a stimulus presentation package for psychology. Unfortunately setting up the development environment for this project is arduous, especially on Windows. Despite the fact that none of the students got set up in time to work on any of the issues, they were enthusiastic about working with the project maintainers to improve and document the setup process. Over the next few weeks we’ll be working with those five students, and with PsychoPy’s friendly maintainers, to do so.
One student spent some time learning about OpenStates, going through the codebase with a mentor and understanding how web scraping works. She attempted to respond to a feature request – adding some code that pulled in committee votes to the Pennsylvania scraper – but discovered that the feature had already been added. The project has piqued her interest, though, and she’ll be working with OpenStates’ maintainers on a yet-to-be-determined issue.
That same student reported an issue with our tasks tracker which we’re hoping to fix soon.
One attendee tackled a bug in BioPython, and was able to come up with a fix to help a program deal with an error gracefully, but wasn’t able to test his changes, as the person who reported the issue wasn’t able to provide the input to reproduce it.
Another student submitted a patch for a problem in gnome-applets where strings weren’t getting translated properly.
One student attempted to fix a problem with the layout in the Privly project website but difficulty with her internet connection meant she wasn’t able to work much on it, and was forced to socialize with students and mentors instead. This was much more successful, if you view having to deal with our puns on IRC as a success. We look forward to seeing her next week at Grace Hopper.
This event kicked off a week with 4 Open Source Comes to Campus events in 3 states, with over 100 attendees.
We had 28 students at this event, with roughly equal numbers of men and women throughout the day. We accomplished this gender diversity primarily by doing targeted outreach and by sending personalized emails to the women who signed up. This enabled us to talk more deeply with them about their interests, and to encourage them to come.
During the career panel, a discussion emerged about the sociology of the free software movement. Some of the recommended reading (all free to read/download):
Coding Freedom by Biella Coleman
- The Cathedral and the Bazaar by Eric S Raymond
Dispatches from the Revolution by Alex Skud Bayley
- The Cost of Collaboration in Code and Art by Benjamin Mako Hill and Andrés Monroy-Hernández
Feel free to recommend more in the comments!
The phrase of the event was “yak-shaving” – the experience of needing to do one thing in order to accomplish another, recursively, until suddenly you find yourself shaving a yak in order to install subversion. Especially relevant when setting up a development environment! Assuring attendees that it’s not just them is one of the most vital things we do.
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.
- 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.
- 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.