During September, we focused on events. We organized a Boston Software Freedom Day celebration and an Open Source Workshop at MIT. This focus on events guided the website changes that shipping during September as the 0.11.09 release.

Training missions changes

Students at the MIT workshop used the OpenHatch training missions. To prepare for that, and in response to bugs that attendees filed, we added some polish to missions. Particularly worth highlighting:

• It’s easier to browse the available missions because of a new visual layout for the missions.
  
• We also added up-to-date explanatory text to the top of the missions page.
• We organized the missions into groups by kind.

As always, if you have feedback on the training missions, let us know!

Events calendar gets time zone support

In August, we created an events calendar for the site at events.openhatch.org. We didn’t publicize the calendar much because it always showed the date in the one time zone configured on the server.

Clara Raubertas contributed changes to the events calendar that let it check the user’s time zone via JavaScript and show calendar events in that zone.

Who contributed

These are the faces of the people who pushed the code forward this month:

More information about the release

If you’re interested to know more, you can read:

• The milestone within the bug tracker
• The release planning page on the wiki

For the future, you might enjoy the 0.11.10 planning page on the wiki!

Image credit: The Time Zone by duncan.

This is just a quick note so everyone knows:

We’re organizing a Software Freedom Day Celebration. The Day is a event celebrated across the globe. It started as an installfest, and we love the enthusiasm behind the event.

We want to know: what are you doing for the day?

I want to give a special thanks to Máirín Duffy for speaking! Her efforts with the Fedora Design Ninjas are a huge inspiration to us, from the way we organized Build It, to the planned Starling bounties, to driving proposed changes to the volunteer opportunity finder.

Here’s our plan:

More details here and sign-up:
http://openhatch.org/wiki/Software_Freedom_Day_2011_Boston

I did a lot of traveling during 0.11.07, so that release covers two months: July and August.

The big highlights are the first implementation of the Buildhelper; new contributors fixing template issues; and a project-wide improvement in understanding of how to build reasonable web app front-ends. As usual, there were some code cleanups that make the backend more maintainable. Read the rest of this entry »

Oops! We haven’t been keeping you up-to-date with release announcements. The last one was in June. The OpenHatch community has been quite active since then; we’ve been giving presentations, organizing events, and working on a new structure. We’ve even been pushing the web app forward and doing software releases. We just didn’t write announcements.

Well, I like announcements. So now seems like a good time to talk about 0.11.06!

June’s 0.11.06: Web forum, caching, and mission cleanup

The big news on the backend for June was the introduction of new web forum to help people chat about OpenHatch in a place that isn’t a mailing list. Mark Freeman took the time to review a great number of forum apps, and we settled on Vanilla. I (Asheesh) wrote the login integration code that lets you use your OpenHatch account to log in.

The big news, design-wise, is that Paul Bakulich implemented UI changes to the training missions so you can visually track your progress through them. The check-marks are new, and if you have not yet completed the step, it will be greyed out:

We also began the slow process of moving our web hosting to the famous Open Source Lab at OSU. Huge thanks to them for offering a virtual server to us!

These people contributed commits to the release:

There were a lot of little improvements that deserve a mention:

• Tiago Sousa (Mkman) adjusted the text on the account creation page to be more clear.
• Paul Bakulich fixed the /projects/ URL to redirect to /+projects/ and uncovered some backstory about why the + marks are part of our URLs.
• Paul also tidied up the display of collaborators on people’s profile pages and made the profile editor UI more responsive. His changes to the git training mission backend fixed user reports of unreliability.
• Jessica McKellar fixed a typo in the git training mission and began to push patches and deploy code as part of her new membership in the Login Team.
• Travis Beatty changed buildout.cfg to list specific versions of our Python dependencies.
• AFMac fixed the diffpatch mission so that it detects UTF-8 byte order mark characters left by some Windows text editors, and warns you. This change also introduces a unit test.

As always, you can read more about the milestone by looking at the bugs closed and the openhatch-0.11.06 tag in git.

I’m writing to announce three big changes for the project. First, OpenHatch is changing its organizational structure to reflect our not-for-profit goals. Second, we’ll emphasize our new work beyond the website, building and promoting outreach events that bring new people into the free software community. Finally, I am taking a year to do that full-time as the project lead of OpenHatch in Somerville, MA.

Transitioning to a non-profit

The front page of the website shows our current mission:

Free, open source software loses tons of prospective contributors because it is difficult to learn how and where you can fit in.

OpenHatch is an open source community aiming to help newcomers find their way into free software projects.

We work toward this goal through this website and outreach events.

OpenHatch was originally founded as a for-profit corporation. This transition to a not-for-profit will bring the legal entity in line with what we have been focusing on.

The website and our outreach events have been a community effort ever since the site launched. The code behind the website has always been free software. We have been holding open conversations on our development list and IRC channel. We’ll keep doing all those things. (As always, if you want to participate, you’re invited to our weekly development meetings!)

Right now, the non-profit organizational structure is a goal, not a reality. In the immediate future, we aim to find a fiscal sponsor to help us take donations, and as this year moves forward, we will be working to establish OpenHatch as a non-profit of its own. We hope to raise enough funds through donation and sponsorship to hire an employee in a year or so.

Outreach events, both on-line and in-person

We believe outreach is essential to grow the free software community. Historically, free software has relied on self-identification and word-of-mouth to turn users into contributors. The result is a community that grows slower than it could, both in numbers and in diversity. Humanity as a whole is an under-reached population.

In the past year, we have worked on three new programs to address this:

• Through the Boston Python Workshop, we’ve brought more gender diversity to the Boston Python Meetup group. This received a warm reception at PyCon and led to the creation of many similar diversity outreach efforts around the world. Jessica McKellar (jesstess) has taken the lead on continuing this effort. It has introduced programming to over one hundred students, the vast majority of whom are women.
• We organized IRC-based tutorials for new contributors to join free software projects. We called these “Build It,” and two projects participated. They directly led to bugs being closed in one of those projects, Vidalia. Moreover, the success of the event inspired Debian Women to organize its own Build It event.
• In September 2010 we organized an introduction to the world of open source for students at the University of Pennsylvania. From this event, we learned about the huge unmet enthusiasm for learning how to participate in the free software community among undergraduates.

Shortly, we will be announcing the next iteration of the university outreach project, bringing open source community members onto campus to grow the community through face-to-face events.

Many free software projects are already running their own excellent outreach events. OpenHatch has always emphasized bringing new contributors to existing communities; with the new focus on events, we will aggregate those events into a universal free software outreach calendar.

Asheesh as full-time project lead

Personally, I want everyone to have the opportunity to shape the software they use on a daily basis. Dedicating the next year to OpenHatch is the best way I see to make that a reality.

This work is too urgent to wait, so I’ll be self-funded for a year as we build up the new organization.

The true force behind OpenHatch has been the collective of volunteers that share a passion for our mission. The OpenHatch website is nearly two years old, and we are lucky to have had twenty-seven contributors to the codebase in that time. Our outreach events have prospered here in Boston and inspired similar efforts around the world. We’re going to continue to operate as a loose volunteer collective, supported by discussion on mailing lists like Devel and Events and our IRC channel.

Okay, that’s it for announcements. I’m excited about spending the next year on OpenHatch without distractions!

My name is Jessica, and I’m an organizer, curriculum developer, and lecturer for the Boston Python Workshop, a free, 1.5 day project-driven introduction to Python for women and their friends. The workshop has run twice, in March and May, and the third run is happening in July at Google Cambridge.

I’d like to share some of the lessons the Boston Python Workshop staff have learned about organizing outreach workshops and our goal of bringing more gender diversity to the local Python community.

First, the structure of the Boston Python Workshop

The Boston Python Workshop is for women and their friends who have no or limited programming experience (I’ll talk more about “women and their friends” in a bit).

The workshop is held on a Friday evening and all day Saturday. On Friday, attendees set up their development environments and start learning Python through a self-directed tutorial and practice problems.

On Saturday, attendees continue learning Python with a 2 hour interactive lecture. Attendees and staff socialize over a sponsored, on-site lunch. In the afternoon, we break out into groups to practice Python while rotating through three short projects on a variety of fun and practical topics. Our projects have included writing parts of a Twitter client, how to cheat at Words with Friends, writing a basic web app in Django, and writing graphical effects for a ColorWall. Our material is all online, so check it out.

This comes to a solid 10 hours of learning and practicing Python, with support from a strong group of volunteers from the local programming and open source communities. The workshop is run under the auspices of the Boston Python Meetup (I’m one of the Meetup organizers) and we hold follow-up events like an open Project Night through the Meetup.

Lessons learned about teaching Python to beginners

There is a huge difference between teaching Python to people with programming experience in another language and people with absolutely no prior programming experience. The biggest lesson we learned is that if you are going to teach absolute beginners, you have to commit to really starting at the beginning:

• Make getting your environment set up a part of the event. If you say that attendees need to install Python and dependencies before the event, you will scare off some beginners. For us, environment setup includes:

  • installing Python
  • on Windows: adding Python to your PATH
  • practicing starting and exiting a Python prompt
  • installing a code-friendly text editor
  • practicing running Python code from a file
  • installing dependencies for the Saturday projects

  We provide step-by-step instructions for Windows, OS X, and Linux. We want people to leave Friday confident in their ability to create and navigate a Python development environment.

• Introduce programming vocabulary before you use it. It’s easy to toss around words like ‘variable’, ‘parameter’, ‘string’, or ‘syntax’ without thinking about it. Define these words as you use them, and tell other staff and attendees to call you out if you start using jargon. Consider having a glossary to which attendees can refer.

• Make it clear that experimenting is okay. This isn’t a sculpture or glassblowing class; there is no physical or expensive resource “wasted” on mistakes, so don’t be afraid of making them. Get attendees in the habit of answering their own questions by testing and tinkering. As much as you can, give answers at a Python prompt instead of saying them. We also introduce tracebacks very early and strip away any intimidation or sense of having done something “wrong” when attendees encounter them.

• Have clear, bite-sized goals. Completing a task, no matter how small, is encouraging and lets you know that you are on the right track. Our Friday night material has explicit steps for each bit of environment setup and ends in a check-off of a handful of key lessons with a staff member.

• Give attendees opportunities to practice thinking about and solving problems in code. It is a huge leap from following along with an instructor or tutorial to solving a problem on your own in code, and it’s a leap that is often neglected in intro material. We have attendees practice with codingbat.com and some staff-written exercises.

• Motivate the experience. Start and end the workshop with why programming is useful, empowering, and fun. Our Saturday projects are an opportunity to experience this first hand. Have the staff share their programming stories.

Lessons learned about outreach workshops focused on women

It is always important to keep a positive, inclusive tone, even when you are focusing on a particular demographic:

• Make it clear that trans women are welcome. I had a tough time coming up with language that I liked, so I asked some trans women I knew for help.

• Make the situation for men clear. Our rule, adopted from RailsBridge, is that men can come as guests of women.

  Here’s how we describe our audience in the Meetup event blurb:

  Audience: Women and their friends who have no or limited programming experience. This event is welcoming and respectful of trans women. Men are welcome as guests of women who are attending.

  Friendly and to the point.

• Talk about childcare. Childcare responsibilities are often overlooked at events like this. Maybe you can afford childcare; maybe you can get a volunteer to watch kids on-site. Even if you can’t provide any help, acknowledging that childcare is a concern for some women who’d like to attend goes a long way towards cultivating an inclusive environment.

• Have female instructors. Studies show that female instructors can substantially impact the confidence and performance of women pursuing science and engineering [1][2][3]. It’s also an opportunity for attendees and the general Python programming community to see more examples of smart, confident, capable women programmers. Need help finding staff? Ask around your local user group, universities, and tech companies.

Lessons learned about sponsorship and publicity

You can’t run a workshop without a venue, food (for all-day events), and attendees. The Boston Python Workshop is a free event run by volunteers, so we have to handle space, food, and publicity through donations, grants, and a lot of on-the-ground effort. Here’s how we do it, from a women’s outreach perspective:

• Ask local businesses and universities for space and food. Don’t underestimate the ability of local businesses and universities to help you with space and food donations. Often all it takes is asking. A lot of bigger companies have budgets for community relations or diversity outreach that they are dying to use on events like this.

• Ask the Python Software Foundation for help. Apply for funding through the PSF grant and sprint programs. PyLadies in LA received a PSF grant for their outreach events earlier this year.

• Short on attendees? Send an e-mail blast. Advertise the event with your local user group (better yet, make it a user group event). Still not full? How about contacting:

  • local chapters of engineering societies like the Association for Women in Computing and the Society for Women Engineers
  • women’s groups at local universities, including engineering and science societies.
  • computing clubs at local universities.
  • local tech companies.
  • local tech reporters and bloggers.
  • the organizers of local Science, Technology, Engineering, and Math (STEM) youth initiatives. Some examples from Boston are Science Club For Girls and Citizen Schools.

  These are all also great communities for recruiting workshop staff.

• Play the social media game. Get on Twitter, pick a hashtag, and promote the event. Write blog posts and encourage attendees to do the same. Invite famous local tech women to attend the event and blog about it.

Lessons learned about goals and iteration

What are the long-term goals for these outreach workshops, and are we achieving them?

In Boston, our goal is sustained involvement in the local Python community. For us, it’s important to:

• Have a roadmap. An intro workshop is a great first step, but what’s next? We end the workshop with explicit suggestions for next steps and reiterate them on our wiki and in a follow-up e-mail. We also specifically invite workshop attendees to a pre-scheduled follow-up Project Night, and since attendees joined the Boston Python Meetup to register for the workshop, they’ll get information about all future Meetup events.

• Be data-driven. We run detailed exit surveys and use that data to iterate on the curriculum and projects. We hold a staff wrap-up shortly after the workshop where we dissect every part of the event from the instructor perspective and identify parts that can be improved. We also track attendance at general Meetup events.

Prior to our outreach workshops, Meetup events were under 5% women. I can happily report that the 6 general Meetup events (which typically bring in 40 – 70 people) held since running our first workshop have all had at least 15% women attending, and we have some fantastic workshop alums who have become Project Night regulars.

Your turn

There is a huge, unmet demand for programming events for women, across the US and globally. Our workshops fill up within hours, and we plan on running the Boston Python Workshop every 2 months for the foreseeable future.

You can read more about the Boston Python Workshop on our wiki. We are #bospythonworkshop on Twitter, and we run under the auspices of the Boston Python Meetup (@bostonpython) and the OpenHatch project (@openhatchery). We plan events and share strategies with other outreach events on the OpenHatch Events list.

It’s your turn! What programming or open source communities are you passionate about? What kinds of outreach are important to you, and what are the biggest barriers to running a workshop in your city? We want to see more outreach events across the globe, so tell us what you need and we’ll help make it happen!

Already a veteran event organizer? We want to hear about your experiences!

Leave a comment with your story and join in the discussion on the Events list.

[1] Gürer, D. & Camp, T. (2001). Investigating the incredible shrinking pipeline for women in computer science (Final Report — NSF Project 9812016).

[2] Sonnert, G., Fox, M. F. and Adkins, K. (2007). Undergraduate Women in Science and Engineering: Effects of Faculty, Fields, and Institutions Over Time. Social Science Quarterly, 88: 1333–1356. doi: 10.1111/j.1540-6237.2007.00505.x

[3] Bettinger, Eric P. & Long, Bridget Terry. (2005). Do Faculty Serve as Role Models? The Impact of Instructor Gender on Female Students. The American Economic Review
Vol. 95, No. 2, Papers and Proceedings of the One Hundred Seventeenth Annual Meeting of the American Economic Association, Philadelphia, PA, pp. 152-157

For an excellent introduction to the gender gap in computer science, see:
Margolis, J. and Fisher, A. (2002). Unlocking the Clubhouse: Women in Computing. Cambridge, MA: MIT Press.

Over 2009, two women worked to bring more people into their programming language meet-up group. Their RailsBridge effort has lessons for community building in free software as a whole.

RailsBridge began as an effort by two women to bring more gender diversify to the Ruby on Rails meetup in San Francisco. Their strategy: teaching Ruby and Rails to women and their friends. (“Women and their friends” means anyone who identifies as a woman may attend, and anyone else must find a woman to bring him as her guest.) As I looked into it more, I read the slides of Sarah Mei’s talk at SCALE. I learned:

• At the start of 2009, the Ruby meetup was 2% female. By the end, it was 18%.
• The Ruby meetup ran three outreach events to women (and their friends) in 2009.
• There was no shortage of prospective attendees. The events fill up sixty slots within 24 hours, and then the waiting list starts.

I believe that in-person programming meet-up events are structurally similar to free software projects: both are totally open, in theory, to anyone who shows up; both usually have appallingly bad diversity characteristics; both are communities where over time, attendees form bonds of friendship; both are highly visible and yet comprised of a small number of people. Finally, in both, attendees often invite their friends to join. So when thinking about how to grow and diversify free software communities, the success of RailsBridge deserves a solid look.

In the case of RailsBridge, over 2009, about 180 people attended workshops; by the end of the year, the meet-up had grew from about two women in attendance to about 18.

Even though they only retained 10%, Sarah and Sarah succeeded at the stated goal: to improve gender diversify at the Ruby meet-up. Because so many attendees came, they needed to retain only small fraction to make the leap from 2% to 18% diversity-wise. By casting a wide net, and limiting the time investment of teachers to a short event, the RailsBridge organizers are achieving their goals without massive burnout.

Originally, I thought the 10% retention was a sign of inefficiency: if the RailsBridge organizers wanted to find more women to attend their meet-up, I thought they could have just personally invited some female friends of theirs. The RailsBridge effort is a dragnet approach, scouring the entire Bay Area for women and their friends who are interested in day of technology demystification. But it is efficient in a crucial way: it created the volunteer enthusiasm that it needed to run the events. In terms of energy expenditure, it seems to be positive-sum.

Here in Boston, in January Deborah Nicholson and I decided to start the Boston Python Workshop for women and their friends. Our goal was to improve gender diversity in the Boston Python meet-up group. The workshop is continuing apace: Boston Python Meetup events are seeing about 16% attendance by women, and our third workshop filled up in three hours.

It’s part of OpenHatch not just because it aligns with our mission of helping people get the skills they need to contribute to free software; it is also an exercise in community organizing in a context quite similar to any given open source project.

The success of RailsBridge also honed my thinking about the Introduction to Open Source workshop that OpenHatch ran at Penn last year. We found local, enthusiastic volunteers to help teach, and the result was a demystification of open source. However, I wasn’t sure if the students went on to become long-term contributors to projects. RailsBridge has the smart strategy of attaching new, enthusiastic people to an existing community; in their case, the Ruby on Rails Meetup group. That’s a lesson we’re carrying forward with the Boston Python Workshop, and one that I’m mulling over for future iterations of the Intro to Open Source workshop. (Focusing on existing communities also led to the Build It series of events.)

Finally, on July 15, we are running a Scala Crash Course for women and their friends. Attendees are expected to participate in Scalathon, a weekend hackathon oriented around contributing to open source Scala projects. As a meeting of open source contributors, Scalathon offers a unique experience to attendees; we hope that the newcomers who learn Scala will enjoy their time contributing over the weekend and find themselves a new hobby.

To bring about our goal of more people contributing to free software projects, OpenHatch isn’t going to be exclusively web-based. We now understand that growing the free software movement is a bigger task than building some web tools. Keep an eye out for more in-person OpenHatch-affiliated meetings and events in the future.

(And if you want to catch wind of how we’re organizing them, or run your own, keep track of them through the wiki page, and join us on the Events mailing list!)

The month of May represented some major improvements to core OpenHatch functionality. The map, the git training mission, our bug tracker importing, and the weekly email to project maintainers saw significant improvements. Keep reading to learn the whole story.

In the OpenHatch community, we have weekly planning meetings. In the start of May, we chatted about what we wanted and wrote up a plan for what we wanted to see. What we worked on reflects the must-haves and what people wanted to work on. Here are the highlights:

• Paul Bakulich and Jessica McKellar adjusted the text that we periodically email to project maintainers to be more helpful. (This email informs them of prospective contributors and other site activity.)
• Asheesh (me) fixed the map at /people/: The old map was only good at crashing web browsers; now, after some major hints from Christopher Schmidt of openlayers.org, we have a rewritten map. It is much more responsive to use (and also much easier to maintain).
• Paul Bakulich, Mark Freeman, and Thomas Noe made the git mission more clear (in its text) and reliable (in its backend). These were Thomas’s first commits!
• Knut Hühne improved the usability of the diff/patch missions.
• Asheesh updated the front page so that, when you log in, there is custom information useful for project maintainers. If you’re a project maintainer, we’d love feedback on how this new space could be more useful to you.
• Asheesh exposed the ability to edit the bug trackers associated with your project by editing your project. (Just go to a project page like the one for Tahoe-LAFS and click “Edit” in the top-right.) This builds on backend code by Jack and frontend suggestions by Jessica Ledbetter.
• Claudio Mezzasalma improved the data snapshots to include tags from people’s profiles.
• Mark Freeman added a “Usual IRC nick” field to the profile (a useful feature by itself, and also the basis of a to-be-created tutorial for new contributors on modifying the profile).

This work represents some major fixes to long-standing problems with the site:

• In the past, the map was too slow to use.
• In the past, the only way to tell us about bug trackers that a project uses was through editing a wiki page.

I’m really glad that we addressed these issues, and I look forward to hearing about the issues that bug you the most, or the features you most need. Join us on #openhatch on irc.freenode.net, or post to the Devel mailing list, and let us know.

These are the faces of the people who pushed the code forward this month:

You can check out the full list of bugs closed during the May milestone. We’re gearing up for the June milestone, and looking to spend some time planning in a more big-picture fashion. Paul Bakulich sent an email to the Devel list along those lines, and during the last meeting we wrote up some goals for the next year, wikified by Karen.

(Image credit: Taste the… Nuts and bolts? by Sasha Wolff on Flickr. Follow the link and read the story behind the photo!)

Late at night on April 30, I deployed the latest release of OpenHatch. Version 0.11.04 is tagged in Gitorious. It was a frantic release with only two weeks of time. We got a lot done, thanks to a really active team with lots of new people!

Here are some highlights of what changed:

• Jack Grigg continued to improve the code that downloads bugs from other projects’ trackers (to display them in /search/). When we download bugs, we now do it in parallel thanks to Twisted.
• As his first contribution, Knut Hühne improved the CSS on the bug tracker. Paul Bakulich further cleaned it up.
• Asheesh and Jack created an extremely basic web interface for managing a project’s bug trackers. It will serve as the basis for a UI that we will recommend people use to have us index their project’s bugs.
• Mark Freeman worked on a training mission to teach git, and Paul Bakulich polished it up well enough to be deployed.
• First time contributor Claudio Mezzalma created a new robots.txt so that people’s dev servers don’t get indexed by search engines.
• We improved the build system: Jessica Ledbetter (for her first patch) corrected the imports so that we can find PIL even in a virtualenv. Paul added Subversion to our list of dependencies to pull in using apt-get.
• Jessica Ledbetter implemented a totally new front page, making the site more consistent. You should actually give that a look: log in, and notice that the layout doesn’t change and the page is much more well-organized.
• We upgraded to Django 1.2 and were careless with CRSF_TOKENS on a bunch of forms; Knut Hühne helped us out of that predicament with an awesome patch.
• First-time contributor Filipovskii Off wrote code that lets us keep track of if you have ever completed a mission, even if you reset it. Also, Jack reviewed and deployed the patch, his first such cycle, made possible by him being on the Login Team.
• First-time contributor Vivek fixed our use of Google Maps so that we now always use the SSL-based API.

This release announcement was not shipped on time. As project lead, mea culpa. Thanks go out to Paul Bakulich for helping me write it!

We were lucky to have some new contributors, as mentioned above. These are the people whose commits made the release possible:

I wrote that we shipped, “bugs and all.” After deploying the git training mission, I tried it out with a more critical eye and discovered that it could use some clean-up in the interface. First thing on May 1, I filed a flurry of issues on the bug tracker. We will hopefully close those by the end of May; we could use your help, if you’re reading this! The best ways to find us are the #openhatch IRC channel on irc.freenode.net and the Devel mailing list. Stop by and say hello.

This month, we could especially use people who like thinking through user interfaces and making mockups we can implement. We can always use JavaScript and Python programmers, people who like doing graphic design, and people who like writing documentation.

(Image credit: “Ladybug Love” by Tony Koloski.)