[Events] After CCSF: Making Open Source Comes to Campus even more hands-on

[Asheesh Laroia]

Hey all,

Last Friday, a bunch of the volunteers from the Open Source Comes to 
Campus event at City College of San Francisco met up. Roan Kattouw 
generously let us use the Wikimedia Foundation offices.

== Background ==

Thre are partial conversation logs here -- 
https://etherpad.mozilla.org/notessss -- and I wanted to share in this 
email a particular suggestion for how to make the Open Source Comes to 
Campus events more focused and engaging.

One important thing to note is, per Katherine's amazing notes 
<http://lists.openhatch.org/pipermail/ccsf-campus-staff/2013-July/000053.html> 
about attendance the event went, there were 41 attendees. This might be 
the largest OSCTC event there has been (it's competitive with the MIT 
event run by Jessica McKellar a few years ago).

== Attempting to motivate the learning through hands-on activity ==

Geoffrey Thomas (geofft) brought up an interesting point: right now, we 
probably have more lecture than needed. He envisions a modified format 
where, to the extent possible, students learn by *doing* even more than in 
the current format.

geofft also remarked that since many students don't get all the way to the 
end of submitting a patch to a "real project", and even if they do, they 
might not get feedback on the patch during the daytime. Plus, with 41 
attendees, Judy wasn't able to merge all the pull requests submitted 
against her repository during the Github demo 
<https://github.com/judytuna/the-new-field> (she only merged one at last 
count, which makes sense).

One way to do that is to adjust the schedule so that the first thing that 
happens is students work in groups of 4 with 1 mentor on doing a sample 
open source project of some kind (any of: do some translation for an open 
source project; submit a patch for a hand-picked with a bunch of code 
mentorship in a project where we have tested the 
build/dev-environment-setup process takes a reasonable amount of time; 
submit a trivial text change to a dummy project on Github, like what we do 
with the Github demo at the moment) for the first 1h30m of the day.

In general, the projects I'm imagining students working on in the 
four-on-one groups are ones where the solutions are known before-hand, or 
where they are simply collaborating with each other, rather than ones 
where students are solving fresh issues in communities that are novel to 
them. geofft pointed out that if students are e.g. submitting pull 
requests to Github during the morning, we could have a team of remote 
helpers not physically at the event who are commenting on their pull 
requests e.g. during lunch.

(I imagine that the TAs would stand at the front of the room and say, 
"Come to me if you want to _____" and after 5-10 min for people to 
self-sort, we'd divvy up unassigned people. We could be fairly broad in 
the number of available projects, or we could be fairly narrow.)

One thing we run into is that students (at different colleges and also 
within them) have different degrees of expertise with the command line. 
Mostly we've found we can do without any sort of explicit command line 
instruction, but periodically we find students where we can't. If we work 
in small groups, the mentor can feel free to take 5-10 minutes explaining 
"cd" and the like. One other interesting thing is that, geofft points out, 
if students have non-command-line ways of doing things (like git within 
Eclipse), then a mentor can just let them use that.

Brainstorming, what other skills can be blended into an initial 
small-group part?

* We could have the mentor ask the attendees go through the laptop setup, 
and make sure all the people in the small group are talking successfully 
on IRC. That way, laptop setup help is something that is easy to get.

* Depending on the task, students could be exposed to bug trackers, just 
as a matter of course of working on the task, and ask questions of their 
small-group mentor to learn more about the 'open source communication 
tools' we stress.

* The mentor can point them to 'git diff' and other ways of generating and 
applying diffs.

* The mentor can actually merge students' work, and possibly cause a merge 
conflict and explain how to fix it. (Mostly, I suspect students would 
benefit from seeing things done at the event and then being handed a 
resource they can use later-on, so it's okay if not all the material is 
presented in a completely memorable way if we also focus on creating 
resources we can hand to students for review after the fact.) (This is an 
improvement over submitting pull requests without being the instructor 
having time to give feedback to everyone, which is what happened at the 
Github Demo when we were swamped with >40 students!)

* The best part of Tom Levine's delivery of "How open source communities 
communicate" talk was when he got super excited showing off the bug 
tracker for "CSV Soundsystem", a personal project of his and collaborative 
data-driven music creation project he works on. If mentors have students 
work on a project with some meaning to them, or at least get a chance to 
talk with a small group about what projects they work on, that excitement 
is likely to be shared.

There are two big lecture-type things that we (I think) clearly can't 
blend into the small group presentation:

* History & ethics of free software

* Career panel

Geoffrey semi-seriously proposed removing "History & ethics of free 
software", but I still think something like that information should be 
part of the event, and anyway we have some plans to revise that so I want 
to see if perhaps post-revision we can come up with something extra great 
there. The career panel seems definitely worth keeping (and there are some 
revisions we can make there, too).

Hypothetical proposed revised schedule:

* 9:45am-10:15: Laptop setup, breakfast + coffee, meet & greet (with name 
tags)

* 10:15 - 11:45: Mini projects time, per above

* 11:45 - 12:15: career panel

* 12:15 - 1:00: Lunch

* 1:00 - 1:30: History & ethics of open source, somehow revised

Which leaves the time from 1:30 PM onward.

There are a couple of things we might do with the remaining 3h.

One thing we don't yet do a great job of, in my opinion, is giving 
students a great way to get acquainted with the massive breadth of free, 
open source software that does exist. It might be interesting to have an 
optional session where one teacher gives a session where they explain how 
to find an open source source project they might want to work on, or use. 
(We'd want to write up a curriculum for that, I suspect.) This is pretty 
important in terms of helping them find communities down the road that 
they might want to get engaged with.

Alternatively, that could be something that happens in a 4-on-1 group at 
the start, just before or after (or during) when students dive into their 
toy project contribution session with a mentor.

If we have a variety of activities of a variety of difficulty levels, then 
basically students could just turn around and work with a different mentor 
in another 4-students-1-mentor session, just like the morning, but you 
choose something else. So this way, you'd become exposed to the technical 
tools and/or community tools behind a variety of projects, and this way 
you'd become exposed to the fact that more than just Github exists.

The post-1:30 time, in this re-envisionment, is a little hazy for me 
still, but I think there is something to this general idea.

Again, you can read the original notes here -- 
https://etherpad.mozilla.org/notessss . I'm quite curious what people 
think.

(also curious to geofft if I got his idea basically right)

-- Ashesh.