[Events] reflections on Reflections | Projections (UIUC) workshop

[Asheesh Laroia]

Hi Shauna, and all,

Thank you for this summary, and also thanks for working with me on the 
workshop! Having you there was a huge help, and I'm hopeful that we can 
run more of these together! (And maybe have you run a branch of them 
without me...? We'll see!)

Excerpts from Shauna Gordon-McKeon's message of Sat Oct 20 17:18:21 -0400 2012:
> On October 6th and 7th, we had our sixth Open Source Comes to
> Campus<http://campus.openhatch.org/>event at the University
> of Illinois Urbana Champaign <http://illinois.edu/> (UIUC), as part of
> their ACM's annual computing event, Reflections |
> Projections<http://www.acm.uiuc.edu/conference/2012/index.php>.
> We did a one hour talk on Saturday the 6th on "getting started in open
> source", as part of the main conference, and then a day long workshop on
> Sunday.  About 25 people came to the Saturday talk, many of whom were
> leaving the area the next morning, including a few people from other
> campuses who expressed interest in having us come run workshops with them.
> 20 people came to the workshop over the course of the next day, with most
> people coming around lunchtime for the last tutorial, food, and then the
> first hour or so of project time.

Ya. Since the weekend was relatively packed, we indicated on the 
schedule that the tutorials were optional: 
http://www.acm.uiuc.edu/conference/2012/openhatch.php

> We started the workshop off a little before 10:30, with a command line 
> tutorial by Bonnie, followed by a Git tutorial by Asheesh.  Both talks 
> elicited a number of good questions, although there were some hiccups 
> in linking to practice exercises.  The Git tutorial was fairly in 
> depth - going into not just which Git commands to use, but why - and 
> it seemed to engage the audience quite well, although it's possible 
> that folks were getting lost/bored but didn't want to say anything.  
> In the future, we might want to separate out stuff that people need to 
> know, vs stuff that's "merely" interesting and relevant.  We also 
> talked about giving folks the option to either walk through the 
> OpenHatch Git mission, or doing a separate Git-based bug fix, as a 
> group.  My main worry is that a lecture format, even with questions, 
> might be preventing users with varying experience/ability/interest 
> levels from all getting their needs met. However, over all, the two 
> tutorials seemed to go over very well.

Yeah! I got a lot of great questions on the git tutorial.

I based the lecture on http://www.youtube.com/watch?v=YwIwi80bXX4 ("Git 
for ages 4 and up") and it ran long-ish; I had practiced it at 50-60 
minutes, but it went to 1h10min or so due to questions and explaining 
things slower while watching the audience and making sure they got 
things. I was hopeful that it would run on the short end of that, and 
then we could have people go through the git training mission as usual.

I like the idea in the future of doing a more practical, and less 
theoretical, lecture for the required part of a git tutorial, and then 
maybe during the projects time, having a break-out session for those who 
want to learn more.

I still think the theoretical is very important, but if all you ever do 
is submit one patch, maybe you can get away without the theoretical.

Also, with the ever-increasing dominance of Github in open source 
project hosting land, students frequently needed to submit pull 
requests. klange (as discussed below) did a great job helping people 
through that, but we should probably add it to the curriculum of a git 
tutorial rather than gloss over it like I did.

> Lunch was from 12-1.  Afterwards, we directed folks to a list of open bugs
> in various projects, and they got to work trying to apply what they'd
> learned about Git and contribute to projects.  The 4-5 remaining staff
> members floated around helping folks, although locating who needed help
> turned out to be a bit of an art form.  (Possible solution: encouraging
> folks to join the #openhatch irc channel, where they might feel more
> comfortable asking for help.)  There were a few people who were
> successfully able to submit a patch, but most people had difficulties with
> the bugs we'd found.  Klange made up good issues for demoing github pull
> requests by having people make trivial changes in his nyancat program, so
> folks did get practice that way.  But our system for finding and listing
> bugs clearly needs to be improved.  To that end, we brainstormed the
> following ideas:
> 
>    - annotate bugs more thoroughly, including an annotation of what OS and
>    development environments are needed, as well as an estimate of how
>    long/complicated a process that set up is

*nod*

>    - get more and better bugs by creating an OpenHatch account on major
>    project issue trackers. We could claim bugs for our account and say "We'll
>    try to get people to fix these on $DATE and relinquish by $DATE2"

Yeah -- I really like this idea!

> 
>  The number of attendees dwindled slowly over the course of the afternoon,
> until the last person left at about 6:30.  By our count, there were three
> women at the event, only one of whom stayed for the afternoon to work on
> projects.  To some extent, this might be due to the gender imbalance in the
> conference as a whole, which also seemed to be pretty skewed male.
> However, we definitely need to be proactive with each workshop in
> attempting to get more diversity in our attendees.

Yeah.

I did reach out to UIUC Women in CS. More lead time will probably help, 
as will having the event run primarily by a women in CS group rather 
than as a part of a male-dominated conference.

After running a few of these workshops with various amounts of lead 
time, it's quite clear that more lead time to the local team ends up 
with better results. So consider me a convert.

3/20 == 15%, which may be comparable to UIUC CS as a whole, and is 
slightly better than the conference as a whole, from what I recall from 
our (Shauna's and my) in-person conversations. But in terms of absolute 
numbers, 3 is really not that exciting of a number, nor is 1 for the 
people who stayed on through the whole event. As the person who selected 
the venue and did most of the publicity for the event, I take "credit" 
for that.

> A final thought - Asheesh and I discussed how to make the workshops 
> more social.  The group Git training exercise, discussed above, is one 
> way to do that.  We could also encourage pair programming (the most 
> satisfying part of the experience, for me, was working with an 
> attendee for almost an hour to successfully fix a bug and submit a 
> patch).  We're also hoping to set aside a space at the next event that 
> is explicitly for socializing, making sure a staffer is there to chat 
> with most of the time.

I'm really excited about this last idea, yeah. After the second-to-last 
person to leave finished submitting their patches to brlcad, he asked me 
how big projects like the Linux kernel avoid conflicts, and so I drew 
him a diagram on the whiteboard and chatted, and that was super fun for 
me. (It's no surprise to anyone on this list that I love talking about 
open source projects and their communities and tools.)

One quasi-problem we've had in the past is that when you finish 
submitting your first patch a project, do you then hunker down and find 
another bug to work on? It seems like a lot to ask of our attendees.

So, instead, we can encourage attendees to chat with staffers as a way 
to give themselves a break. I really like that.

As for encouraging pair programming -- yeah, I think that's worked out 
great, and we should work to structure it into things. More in a 
soon-to-come email about the JHU event.

-- Asheesh.