[Events] "Internal" notes after the RPI campus.openhatch.org event
asheesh at asheesh.org
Fri May 4 23:51:08 UTC 2012
Hey all events people,
Christopher Schmidt and I wrote a blog post about how awesome the RPI
campus.openhatch.org event was. It's up here:
In this email, I'm going to ramble about how things could have gone even
better. It's here as a form of memory so that next time we do events like
this, we remember these problems and can make new mistakes, not old ones.
Before I go into the negative, though, let me harp on the positive:
Exit survey responses were quite positive, both from experienced people
and newcomers. They said things like:
* "I think it was well organized & a lot of us could benefit from it."
* Newcomer: "Overall it was a very informative workshop because it gave me
a good concept of what it's like to actually participate in open source
threads and to actually submit code to said threads. So for someone
looking to get involved, this is valuable information."
* Experienced person: "I've been in FOSS for around 6 or so years and I
wish I had had a primer like OpenHatch back when I started."
So that's great! I'm also thrilled by our sponsors -- RCOS, Nokia, and
Kitware -- who each understand the importance of community-aware open
Okay, so onto the rest. Not all of this is negative; it's just things that
deserve extra thought. I'm also trying to write this somewhat briefly, so
pardon any short-handing, and feel free to discuss any of these.
Gender as a text field: this works just fine! We have 100% response rate
to this question in the UMD and RPI surveys, and so far they separate
entirely cleanly into "Male"/"Female" (or what I would call obvious
abbreviations thereof). I am pleased by the idea that we can accommodate
anyone who wants to answer differently, and yet still provide high-quality
reporting if we want to summarize.
Sat morning laptop setup can be shorter. (This showed up in the exit
survey once as well.) At UMD students were finished with the laptop setup
instructions within 30 minutes, often less. That was amazing to me, and I
figured it was a fluke. RPI students also finished easily within 30
minutes (might even be 15-20 for most). I had written down in my notebook
on paper at UMD that students should have practice with using a plain text
editor, and so I added that to the RPI laptop setup instructions at the
last minute, but that still didn't stop RPI students from being done quite
I planned to stay on schedule, and we did that quite well on that. I
didn't communicate clearly before-hand to the Saturday afternoon
instructors how much time each session would last, but things worked out
okay because I told them at the start of each of the sessions. We ended
about 10 min late because Christopher Schmidt didn't have the heart to
interrupt his students as they were reaching the end of the git training
mission (that room was the one that generally needed the most time).
Pseudo-random note: The program 'bb' still has problems with sound
One of the groups had students who had much more difficulty (perhaps due
to being newer to FLOSS) than the rest; and one group was way ahead of the
others, being composed mostly of experienced open source contributors who
were part of the RCOS computing club. Interestingly, all groups seem to
say they learned a lot, even the more experienced ones, so the event was
still useful for them. I noticed at UMD that students with little command
line experience learned a *lot* during that session, and that the
knowledge they gained would have helped them in the other sessions.
Therefore, with RPI, I asked students to self-assemble into "Low" "Medium"
"High" experience level, and had the "Low" ones start with the command
line module. It could be that having a "Choose 3 of 4" or "Choose 2 of 3"
structure would help people get all the command line help they needed; it
could also be that we can take better advantage of the morning time.
Retention between Saturday and Sunday was not excellent. It never is 100%,
and I don't expect it to be. It's generally in the 50-66% percent range at
other such events; this time, it was closer to 50%. I think we can do
better on this point. Some of the people we lost came and spoke to us to
say they couldn't make it; for others whom we silently lost, I wonder if
we could have done something different to retain them better. In
particular, helping students pick a task + community on Saturday, and also
rearranging the times so that the students most in need of help get the
most help on the basics. That way they leave Saturday more reassured of
what they've learned, and with something specific to look forward to.
On Sunday, one student spent a long time building Mozilla. Another spent a
long time building ITK, running into a problem where ITK's CMake would
create files with filenames that were not permissible on his FAT32
secondary disk partition. (Both did succeed, including getting all the way
to contributing patches!) Christopher Schmidt suggested that if attendees
can figure out by the end of Saturday which project they'll be
contributing to, they can start the build (or whatever) that evening so
that their computer has had some time to do computation.
In terms of photography, Chris did a great job of photo-taking. I was too
busy lead-teaching a Saturday module, and I'd like to avoid that role if
possible in the future. I had some difficulty getting commitments from
prospective teachers; perhaps in the future I should plan to have a e.g.
10-20 min phone call with prospective staffers rather than just trade
Pizza ordering on both Saturday and Sunday was good (in terms of enough
pizza) and on-time. Still, we have the following problems. We can make a
checklist for future pizza ordering that makes sure we take care of all
* No plates or napkins (worked-around with paper towel, but should be
properly fixed for the future)
* No drinks on Saturday (fixed on Sun)
* Arguably, lunch was too long, at one full hour
On the first day, basically all the donuts were eaten. (We bought two
dozen.) We bought two boxes of Dunkin Donuts coffee on the first day; only
approximately one was used.
OpenHatch having sponsorship from Kitware was exceedingly helpful because
it gave us some financial flexibility: when RCOS students got soda on
Saturday, I could take the receipt and personally ensure the person got
Men were more over-represented than usual for these events. Based on
sign-ups, we were at about 22% women. To learn why it was so low (I
expected 30-50% women, our usual proportion), I talked with Alex Gaynor;
he showed me that RPI's undergrad CS women percentage is slightly under
9%. In theory, then, we have actual cause to celebrate; our event was
dramatically (>2x) more diverse then that, gender-wise. (Reference:
http://www.cs.rpi.edu/people/students/statistics.html ) Still, that was
In my "Getting, modifying, and verifying open source software" session,
some students tried to take notes, which was made difficult by the way I
was using Etherpad. It would have been better to use slides, and to
publish them afterward; it's a format more students are used to.
On Saturday, I had to ask Moorthy to give us a power strip because I
didn't check that power was easy to get in all of the rooms. It turned
out not to be easy to get in the room we added at the last minute, which I
thought had the same layout as the others, but it didn't. I didn't check
that room on Friday night, believing it to be similar enough to the other
two that I did check.
We did used a staff email list this time; for UMD, we didn't, and I'm glad
we did. Still, I should have gotten phone numbers from the staffers and
scheduled a phone chat or something else higher bandwidth.
On Saturday, TAs didn't follow teachers around. I didn't give them enough
firm instruction that they would follow teachers around, so we didn't get
as much as we could from them in terms of them being able to help
On Sunday, it would have been nice if other people had been roaming the
room more aggressively to help stuck students. We had a few TA-type people
who probably could have, but weren't given enough firm instruction that
this is what they should do. This also happened at UMD, and from this I
conclude that we should make this purpose of TAs much clearer.
One way to mitigate some of this would be to, after that phone call, send
the TAs/Instructors an email with a template; they fill out the template,
indicating which parts they're going to help with, and they send to the
>From the feedback of our staffers, it seems that having concrete slides
and exercises, rather than just a sketch of them, would have been
preferred. If we do that, though, I'm concerned that instructors might
just load the slides up for the first time when they arrive. We should
probably offer the slides and add some hack that
Chris was at first resistant to the "break into small groups" idea, but
upon seeing how it worked, was a fan. That was good to hear.
That's what I can think of for now. In the future, we should turn these
problems etc. into a set of checklists that we follow for future events.
Oh, and I kind of hope that some press people are on this list and use
them for fodder to write about problems with our events. Then I'll know
we're really making it! (-:
Having a local friend-of-a-friend to host Chris and me was excellent. Mega
thanks go out to Casey Goodwin for hosting, and Mo Duffy for making the
More information about the Events