[OH-Dev] improving our 'first tasks' for Open Source Comes to Campus Events

[Asheesh Laroia]

Hi Shauna! Pardon the delay.

Shauna, thanks for getting this started! We should probably involve the 
Events list in the conversation, too.

I'll ramble aloud for a bit about these first contribution experiences, 
both some problems, and some possible solutions.

Going from past event notes here 
<http://www.asheesh.org/note/debian/sep-2011-bsp.html>, one issue that can 
occur is that one staffer suggests an attendee work on a particular task, 
and then the attendee asks a different person for help. In "Mentees didn't 
always get high-quality help" on that page, you can see this led to some 
confusion. (We successfully addressed the confusion and the mentorship was 
a success, but it's an issue that can make it less smooth.)

Semi often, an attendee gives up on a task rather than asking for help. 
This happened at Wellesley because a student hit an issue she didn't 
understand; unbeknownst to me, for a while, she was looking at the task 
list again rather than addressing the issue. I talked her through the 
task, and we figured out what her problem was, and she ended up submitting 
a high quality update to the ticket.

One way to address both of these issues might be a change in mentorship 
style: if only a handful of "lead mentors" have read in-depth all the bugs 
available to work on, maybe it makes sense to assign a non-lead mentor to 
a student (so that the student doesn't have to spend time re-explaining 
the issue to a different mentor), and when the student takes the task, the 
non-lead mentor is approximately required to have a conversation with one 
of the lead mentors where the lead mentor shows the non-lead mentor 
everything they know about the task/codebase/community (to save time for 
the non-lead mentor and to maximize the helpfulness the non-lead mentor 
can provide).

Some projects make it hard to find the source code to the project. This 
happened to the student I mentioned at Wellesley, who was looking at the 
GNOME websites, and could not find the appropriate source. But it can 
easily apply to others. I'm of a few minds here. On one hand, the ability 
to find the source code link from an arbitrary open source project page is 
a very useful skill. On the other hand, we don't need to necessarily have 
students spend time learning that if they don't have time to find and fix 
bugs in the projects' source code themselves. We could let the lead mentor 
solve this in real time, or we can just pre-find source code links to all 
projects that are part of that day's event. It'd be nice if there were a 
standard we could encourage OpenHatch-affiliated projects to follow, even 
if it's something hidden in the HTML source code of the website for the 
project, like a META tag. For example, we could ask projects to follow 
Joey Hess's rel=vcs microformat: http://joeyh.name/rfc/rel-vcs/

Another issue is that sometimes students team up, but aren't good at 
working together, then split up, during the course of the projects time. I 
saw this happen at Amherst where we had relatively few tasks in Java, and 
more students with Java experience than we had great tasks for them.

Another issue is that sometimes students need more context. At RPI, one 
student with limited programming experience was asked to copy bug data 
from one bug tracker that the project used to use (OpenLayers' Trac bug 
tracker) into the bug tracker they were using now (Github issues for the 
openlayers/openlayers repo). He did this for one or two bugs, and then 
asked for more context as to what this meant. Christopher Schmidt (who 
used to be an active maintainer of OpenLayers, but had already stepped 
down by the time the RPI event happened) patiently explained what was 
going on: the new development team hadn't had time yet to move 
contributions by others that took place on Trac. If this is an issue with 
the event, or simply a student question, it's hard to say; I believe the 
student got the context he needed. But maybe there's room for some kind of 
templated textual information summary to the student as to what the task 
means. On the other hand, in this case, I think an in-person explanation 
was required.

At UIUC, I handed what looked like a simple bug in GNU patch to two 
students who had experience with C and using GNU utilities. The bug was 
that there was an error message that could be more useful. I thought the 
issue was as simple as editing the error message printing code to add 
slightly more information. However, instead, it turns out the information 
required to print that improved error message wasn't available at the time 
the error message needed to be printed. At this point, the students who 
were working on it started poking around in the C structs used by that 
codebase. If they had a smart code indexing tool, like OpenGrok, that 
would have helped them tremendously. In the end, they were unable to 
figure out where the issue could be fixed.

At UMD, a student approximately shocked me by asking, "What open source 
software is there?" I've spent lots of my life finding out what exists, 
has been updated, or is new, so I forget that people don't know this. And 
at Wellesley, one student expressed an interest in music-oriented open 
source. It might be kind of nice if we had a corner of the room dedicated 
to finding open source projects the students might care about. Perhaps 
just assigning that role to one mentor, and having the students watch as 
that mentor uses websites to do the search, and narrating aloud, would 
probably be illuminating.

Personally, I think one of the best things you can do as part of joining 
an open source project is to lurk on its development mailing list. After a 
few months (!) of this, if you pay attention, you get to understand the 
people involved and the code involved.

One issue we've had is that students don't have a way to stay on IRC after 
the end of the day. As usual, I'm of a few minds; on one hand, I want to 
emphasize that IRC clients can actually look nice, like Adium. I also want 
to discourage people having to think about special configuration options. 
On the other hand, I want people to have access to an IRC bouncer or 
something like that; perhaps that would mean configuring their IRC clients 
to use a bouncer we run as their "server" rather than "freenode" as their 
server. I'm semi unexcited about running an IRC bouncer for all these 
students, but maybe we can find one that is not much of a pain to keep 
running.

I mention it as an issue because it's at least as good a way to get to 
know communities as hopping on the email lists, but the barrier to entry 
is way higher. It'd be great to have a bit of process toward the start of 
students looking into a bug which is almost mandatory, to get students to 
say hi to the community.

I also think that one of the missing angles of Open Source Comes to Campus 
is getting students to just *use* more free software, themselves, on a 
daily-ish basis. Preferably random small command line utilities or web 
browser extensions because small programs are usually easy to report bugs 
against. Then just joining the mailing list and saying "hi" would be a 
pretty noticeable contribution, since the maintainer would feel like they 
have more users.

As for your question, about a generic guide for setting up development 
environments, I know of no such thing. We made 
http://labs.openhatch.org/foss-contrib-guide/ and we/I could put something 
together. Here is what it would look like, as an outline:

* Make sure you have a text editor

** gedit/smultron/notepad++

* Make sure you have the relevant code

** mkdir -p ~/projects/this-project
** cd ~/projects/this-project
** git clone whatever

** You might need to install the relevant version control tool. Links to 
svn and hg and git and whatever else home pages, and hopefully we test 
that the click path from there is actually likely to yield useful 
results.

* (Usually) Create an area where it's safe to unusual versions of 
software the app depends on

** For languages like Ruby and Python, you'd use bundler or 
virtualenv.

** For C etc., uh...

* Install dependencies as required, as you figure them out

** if you're lucky, the app told you how to do that, e.g. pip install -r 
requirements.txt in your virtualenv

** if you're hacking on a C-ish thing and have a great operating system 
installed like Debian, 'apt-get build-dep packagename' does the trick 
(many people don't know about this, and it is mega awesome)

For estimated time, uh... well we can estimate this by looking at how long 
the related Debian packages take to build on the Ubuntu or Debian build 
daemons. I just tested this, and it seems to be a feasible way to do 
things. For example:

$ getbuildlog libreoffice "" i386

downloads a few libreoffice build logs. They can be grepped for the 
string "Build needed" which shows, e.g.:

$ cat libreoffice_1:4.0.3-3_i386.log | grep "Build needed"
Build needed 05:29:43, 14671300k disc space

It's within reason for us to automatically extract this out.

For your question about feature requests -- I would say, any feature 
request that we have high confidence would be accepted, and have high 
confidence doesn't require changing much code, would be fine. I personally 
think "help requests", where students at Open Source Comes to Campus 
events answer users' questions, should be considered extremely on-topic.

That's a long email. Let me know if I missed anything or should elaborate 
anywhere.

-- Asheesh.