This site is an archive; learn more about 8 years of OpenHatch.

[Events] A critical review of the Penn Open Source hackathon

Asheesh Laroia asheesh at asheesh.org
Fri Sep 9 21:34:55 UTC 2011


Hello all events people,

In the process of preparing for the next set of Open Source Comes to 
Campus events (as per campus.openhatch.org), I thought I would take some 
time to write out what did not work excellently about the event that Yuvi 
and Felice and I organized at Penn.

There is a lot that went *great*! Those parts are easy to remember, 
though, and easy to clone. So here is my list. I intend to come back to it 
when planning the curriculum for the online "beta" version of the class, 
plus when organizing the next set of in-person events.

Many of the good things can be found at the article that I wrote for 
opensource.com: 
http://opensource.com/life/10/11/introducing-students-world-open-source-day-1 
and 
http://opensource.com/life/10/11/introducing-students-world-open-source-day-2

Curriculum problems
-------------------

You can find a snapshot of the planned curriculum here:

http://asheesh.org/scratch/Penn_open_source_hackathon

The old curriculum had "modules", which were self-contained sections of 
material.

In the curriculum, there are "four" modules:

* Communication
* Getting, modifying, and verifying open source software
* Project organization
* Linux and the command line

Students rotated between the modules, and the teachers stayed put. This 
meant a lot of upheaval for students. It would have been easier if 
students could stay put.

The modules had unstated dependencies between them. This was clear during 
the getting+modifying+verifying software module, when we asked students to 
type basic commands into a terminal, but some had not enough experience 
with the command-line to be able to do that.

The teachers didn't have our lectures practiced well. We had wanted an 
even split between lecture and activities (because I believe in hands-on 
learning). However, due to the lack of practice, teachers (myself 
included) spent too long lecturing, leaving not enough time for 
activities. As the day went on, stump and I fine-tuned our section of the 
curriculum so that we could do the lecture part in 30 minutes, showing 
that practice is all it would take for that to work.

There was no hand-out that students could refer back to. Much of the 
material was new to many of the students, surely especially those that 
learned a lot during the command line tutorial section. I fear that 
retention of the material we taught was low, and that if students had a 
hand-out to refer back to, they might be able to retain more of it. In my 
module, we did create a PiratePad document with relevant info; from 
watching people in the Scala Crash Course, I now believe that a printed 
document would be better so that people aren't forced to switch the active 
window so often in their web browser.

The exercises weren't social enough. They were interesting in many cases, 
and quite instructive, but I wonder if role-playing could have added an 
interesting dimension (and taken advantage of the fact that we had people 
sitting there in the same room). I'm thinking particularly also of the 
fact that it might be hard to get P2PU students to do reading and writing 
exercises, but I think they're reasonably likely to do role-playing things 
between the students.

During the IRC part of the tutorial, we didn't talk about pastebin. That's 
criminal. (-:

Instructors didn't have a solid sense of what the other instructors were 
teaching. This led to some wasteful overlap.

The command-line basics section should be sure to cover pipes. I don't 
believe it did. (We could even teach people about piping to pastebinit!)

In the project organization module, we did talk about the idea of building 
and modifying source code. We didn't talk about the fact that 
documentation also has source code, and therefore it has a build process, 
which is probably a new idea for many of the attendees.

We never talked about debuggers. Many people experience these quite late 
in their software development careers. The minimal way to treat this is to 
have a "simple" debugger training mission, and say, "If a project talks to 
you about using a debugger, do that training mission. We don't have time 
to cover it today on Saturday."

We didn't spend much time talking about what makes a good, reproducible 
bug. This is something that a role-playing game could help with.

One thing that I've been hearing from people who are excited about open 
source is, "I don't know how to approach a community and say I want to 
help." I think that giving students an answer to this question is truly 
the point of the event, so we should pay attention to this going forward.

Related to that point, we didn't have exit survey. It would have been 
useful. It's probably the case that we could make an exit survey and ask 
some of the students to fill it out now, a year later. I wonder.

Other schedule items on Saturday
--------------------------------

We held a discussion section where all groups came together and listened 
to a talk on licensing and economics of FOSS. This worked pretty well as a 
conversation between Zach Goldberg (a Googler) and me. Zach contributed a 
lot, and it ended up being something like a Q&A session with Asheesh, 
where Asheesh showed his breadth and depth of knowledge of the history of 
FOSS and the ethics and urgency of the movement.

In fact, one student came up to me after the discussion and 
enthusiastically told me that she now understood the ethics and urgency of 
the movement! That was one of my favorite parts of the weekend. She was 
put off by the use of the word "hack," though, she explained, but she 
managed to get over it. You could call that a negative thing in terms of 
being a distraction from the real point of the event.

You can see our use of the word "hack" here: 
http://penn.openhatch.org/old-index/

In the future, we should call Sunday a "project day," not a "hack" day, it 
seems.

The only major "bad" thing here in the history/economics talk was that its 
scope expanded quite a bit. We should declare up-front that the scope *is* 
to be about ethics and history, as well as licensing and economics. An 
expanded scope is a good idea, and we should plan on it.

We had some people leave during the day, maybe 5 or 10 left before the 5 
PM wrap- up. It would be good to check in with those people to find out 
why they left. Perhaps we can track people's attendance by the end by 
having a sign-in sheet that they check a box next to if they are there at 
the end of the day. Yuvi suspected that a greater proportion of the young 
women left than the young men.

Related to that, we had no women teachers except Felice, who was 
enthusiastic but not a years-experienced FOSS person like the other 
teachers. It would be nice to have even more women in attendance as 
teachers/organizers, especially those with more experience. I do think we 
had an environment that was respectful and welcoming of gender, despite 
our male bias.

The give-away portion, at the end of the day, wasn't super well-organized. 
We asked Bitbucket and Github to give us account codes that we could give 
to attendees, and that was cool, but the attendees just asked us, "Which 
should I pick: Bitbucket or Github?" I found myself saying, "Github, 
probably." It would have been nicer to give people more clarity here. 
Also, with handing out the free books (which Yuvi did great work in 
finding donations for), I recall a little bit of disorganization.

We didn't have the actual Github tokens on us; instead, we emailed them to 
the students. I think actually Yuvi asked students to email him? Anyway, I 
remember him noticing that we didn't use up all the donated Github account 
tokens.

Sunday hack day
---------------

Sunday had some major problems. You can read the optimistic version of 
this report here: 
http://opensource.com/life/10/11/introducing-students-world-open-source-day-2

First, generally, attendance was low. We probably had about 15 people come 
in over the course of the day, which is fewer than the 30 who came in on 
Saturday. This did result in us having far too much food on Sunday. We 
could afford it just fine, but it was kind of sad.

People sort of trickled in. I wonder if we should have asked people to 
pick a 3-hour slot; maybe when they signed up for the event, or maybe 
during Saturday. We could "pitch" the Sunday thing to students during 
lunch, for example, and have signups post-lunch.

One good thing that happened was that some people who did *not* come on 
Saturday came on Sunday. That's what we wanted. That probably accounted 
for 2-5 of the attendees. We could have done better in getting 
non-Saturday people to attend the Sunday portion.

Students spent far too long doing development environment setup. Some 
students wanted to work on an Android project, led by Yuvi and his father, 
which meant a long expedition in getting Eclipse installed and the right 
version of the Android SDK going. That would be fine if it were fast, but 
it wasn't a streamlined process, so it was a big time suck.

For Saturday's learning day, I found a Firefox bug that looked quite easy 
to fix; it had a patch, and just needed style fixes. Some people tried to 
build Firefox and test the bugfix. In general, this was a good idea. 
However, Firefox takes a long time to build. This was especially true on 
Windows, where one person waited for about two and a half hours and 
finally gave up and installed Ubuntu.

One student enthusiastically wanted to hack on Sugar, after having 
attended a talk by Walter Bender. So she attempted to get it installed in 
VirtualBox, which should have worked. She already had VirtualBox 
installed, and she tried to run the virtual machine image, but one crucial 
piece of the VirtualBox UI was simply greyed out on her Mac for reasons I 
could not figure out. I did send her to #sugar, where she did receive some 
help, but not enough for her to be able to get it running.

It would have been nice to have more helpers on this day, probably.

We did have two success stories, but I don't think that anything that 
happened on Sunday directly led directly to anyone becoming involved with 
a project.

I think that a lot of people's heads were still spinning after the 
intensity of Saturday. It would have been nice to have some sort of open 
Q&A session to figure out what was still confusing on Sunday, perhaps by 
dedicating a corner of the room to that. I wouldn't want to make it a 
separate room because I like the idea of everyone being together and being 
able to see the exciting activity of others.

If we had a hand-picked list of about 10 bugs in about 7 projects for 
people to work on during the day, that would have been better than just 
throwing them at the OpenHatch volunteer opportunity finder. It would have 
been even better if we had play-tested the build instructions, and 
narrowed it down to a science. We could totally encode those build 
instruction steps into the "Buildhelper" tool on the OpenHatch site for 
those projects.

This leads me to think that "Hand-picked, highly-recommended volunteer 
opportunities" would also be good to have on the OpenHatch project page 
for a project. This conclusion also comes from my experience with an 
MIT-based hackathon on Debian, see also 
http://www.asheesh.org/note/debian/sep-2011-bsp.html

Community
---------

One thing I noted in my PyCon talk was that we left the Penn students 
without a community. We did create a penn at lists.openhatch.org list.

The list's history looks like this:

* Sep 30, during the week after the weekend event, Yuvi (co-organizer) asks
   if people want to have/attend an Ubuntu 10.10 release party. People respond
   fairly enthusiastically. The Facebook page for the event suggests it did
   actually happen, with people attending! Yay!

* Then Yuvi asked people what they wanted the next event to be, and people
   made suggestions, but then presumably Yuvi got exhausted/busy and didn't
   organize it, and then the list fell silent.

* During the silent phase, I felt sad that the list had "died." Since I wasn't local,
   I couldn't help organize events that could revive the in-person community.

* I sent two announcements of OpenHatch-y events to the "dead" list. They were
   both "Build It" tutorial events. I don't think any Penn people made it to those
   IRC-based events.

A more sustainable model would be to tie the future "Open Source Comes to 
Campus" events into a local community, like an ACM chapter that is active. 
That way, people could have friendly locals to ask their questions of.

We've sort of beta-tested this model with the Boston Python Workshop; the 
newcomers that the event brings in do attend general Boston Python Meetup 
meetings, and the that they sign up for the event forces them to be on the 
main Meetup mailing list (unless they carefully remove themselves). Having 
the regular-ish hack nights are really good for continuing the enthusiasm. 
The fact that Boston Python Meetup already runs events makes it easy for 
it to create events that new people can attend.

Okay, that's it
---------------

That's that for that for now.

-- Asheesh.


More information about the Events mailing list