[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