[Events] "Internal" notes after the RPI campus.openhatch.org event

[Asheesh Laroia]

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: 
https://openhatch.org/blog/2012/openhatch-goes-to-rpi-concluding-our-spring-2012-university-tour/

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 
source development.

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 
soon.

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 
sometimes, sadly.

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 
emails.

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 
these things.

* 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 
reimbursed.

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 
sad.

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 
students.

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 
staff list.

>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 
connection.

-- Asheesh.