[Events] Making "projects time" hopefully more engaging, within open source comes to campus

[Asheesh Laroia]

Hey all,

Over the past Open Source Comes to Campus workshops, I've noticed that 
relatively few people seem to get all the way through to the end of the 
"Contribute to an open source project" exercise that we set aside time 
for.

There are myriad reasons, and so I wanted to share some problems I 
perceive that we have, and changes I plan to make, in the hopes that 
they're informative to y'all for your own events or that you have thoughts 
on how to make even better changes for Open Source Comes To Campus events.

== Overview ==

The way it generally works is that, after lunch and tutorials, I stand up 
in front of the room, explain a bunch of bugs that seem fairly bite-sized 
to the room, and then students look at a wiki page or Etherpad document 
listing those tasks.

They work by themselves, or in groups, on these things, raising their 
hands as they need help, and then mentors roam around and help them.

== Perceived problems ==

These are the problems that I perceive with this approach:

* Many students aren't familiar with a whole lot of open source projects 
-- for example, students running Mac OS are unlikely to know anything 
about GNOME -- so a task that seems compelling to me isn't necessarily 
compelling to a student attendee.

* Development environments are approximately always a nightmare to set up, 
so that's a time sink with some large risk factor that it will not succeed 
in the time allotted to the projects part (2-4 hours, usually).

* I know a lot about a great deal of software, so I can go look at a 
random error message in a random open source project and know what kind of 
problem it is exhibiting. But since these are less-experienced programmers 
than I am, they often can't, so then they need mentor time...

* ...which is fine, except that mentors aren't always familiar with the 
particulars of the project either, so they often need my help as well, 
since they don't have time during the workshop to go download the code for 
the project and set up a development environment just to make sense of the 
bug.

* Code-oriented fixes, and generally fixes that require approval from the 
maintainer, mean that for the students' experience to be a success, 
someone else has to approve the work. This means that they can't leave the 
event knowing they've had an impact; they have to wait a while. Sometimes 
this is extremely rewarding, but it is high-risk.

* Students sometimes work on the same tasks as each other, just neglecting 
to take "ownership" of a task on the Etherpad or wiki.

== New plan ==

Here is my new plan; curious for y'all's thoughts!!

In addition to the standard format of "Student takes a task and works on 
it by themselves", we'll add a "group" format, which works like this:

* Student pairs up with another student.

* Pair of students finds a mentor.

* The mentor has a list of bugs they are familiar with, and demonstrates 
the problem to the students. The conversation ends with, "Can you help me 
fix this?" and the mentor mostly pretends to be a user who knows how to 
build the program but not how to fix the issue. This makes it vividly 
clear that fixing the bug helps real people. (This requires making sure 
mentors understand this is part of their job.)

* Students work together, pair-programming-style, on finding the cause of 
the issue, and they try to fix it, and the mentor tries to apply their fix 
locally and see if it really does the job. Only then do they submit it 
truly upstream.

That's the plan for code-oriented (and in-tree doc-oriented) tasks. 
There's another thing I'm adding, which is the ability for students to 
work on non-code tasks. These usually have the advantage of being 
lower-risk, yet they are extremely useful; they are actually essential!

I wrote up one such task here: https://openhatch.org/wiki/Answer_questions 
-- and would very very much appreciate more suggestions for future tasks 
to add along that vein.

Currently mulling over the following, to get the creative juices flowing:

* Translate text

* Make a screencast (of how to do the basic usage tasks with an app)

* Reproduce a bug, and leave a note on the bug saying you could do that

== New, hackish volunteer opportunity finder ==

One last thing: I made a new, Javascript-based mini volunteer opportunity 
finder. This shows just hand-picked bugs, but it's super easy to modify 
the code of, and so it might be helpful to merge changes here into 
https://openhatch.org/search/.

http://linode.openhatch.org/~paulproteus/tmp/tasks/

-- Asheesh.