[OSCTC-planning] Improving Open Source Comes to Campus' projects time

[Asheesh Laroia]

(Context: "project" here means "open source community" e.g. "Firefox", and 
"bug" means "a specific task to work on" like any particular Firefox bug. 
"Projects time" is the second half of OSCTC events, where attendees try to 
submit real patches or make other contributions to real open source 
communities.)

Typically, when it's "projects time", what we do is that Asheesh (who is 
the only one who knows about all the projects, and has read through all 
the bugs we recommend during that day) stands at the front of the room, 
rattles off a list of open source projects that people can work on, and 
then all mentors are expected to help with all projects.

This has a few downsides:

* It is hard for mentors to get to know all of the dozens of bugs, and 
unrealistic for them to review all of them, so every time someone requests 
help, the mentor probably is stating from scratch in terms of 
understanding the project's community, and understanding the issue.

* Some mentors have specific bits of experience, like knowing Python well, 
that would make them well-suited to mentor students who are working on a 
subset of the projects.

* When Asheesh is talking about a variety of projects, students have 
little to latch onto -- if they remember they liked a particular project 
he mentioned, but don't remember all the details or the full name, they 
have to ask around to figure out which project that was. Not all mentors 
will necessarily know about all the projects, either, so anyone with 
questions probably has to ask Asheesh.

* Students often end up working on similar or the same tasks, in different 
parts of the room, resulting in duplication of effort and duplication of 
frustration, when instead if they worked together, they would probably be 
more likely to solve the issue.

I propose the following changes:

* We (whoever the the event's lead organizers are) create a list of the 
projects that have good bugs for that day's workshop. (Well, this we 
already do.)

* We then find one mentor willing to be the "champion" (a completely 
made-up term; feel free to come up with a better one) for that project.

* That person is responsible for having read-through all the bugs in that 
project, so that if a student is interested in working on that project, 
they know they can ask that mentor and get a good answer as to what bug 
they might enjoy working on. They could do this at lunchtime if they like. 
They also should have some familiarity with setting up the dev environment 
for that project.

* When projects time begins, each mentor stands up at the front and 
briefly explains the project that they're champion-ing. (We (the 
organizers) could write the project descriptions for the mentors, or 
instead we could ask them to come up with those descriptions themselves.)

* Then the mentors say, "I'll be in the front left" (or whatever corner 
they'll be in), and then the students can show up to that area of the room 
if they want to work on that project.

* We make sure students know it's OK to wander off if the project is a bad 
fit. We do ask that they talk with the mentor whose area they're leaving, 
so that way they don't simply leave because they can't get the dev 
environment working.

* We stil have some roaming "software whisperers" who are not mentors for 
any particular project, but are general development environment fixers, 
who those mentors can call upon for backup assistance with their students.

* In the past, we've had some mentors who are quite unsure what to do 
during projects time. I think this will help them be more engaged.

* This way, we can assign some mentors to help with general topic areas, 
like "scientific computing" or "computer music", and then they can help 
introduce students to a variety of projects within that focal area, in 
order to help the students get a general grounding as well as motivate a 
particular task.

Optional:

* Mentors should buddy-up so that there are actually a pair of projects 
and a pair of mentors. That way, if one project has massive curiosity, 
that mentor can spread the mentoring reponsibility with the other mentor 
whose buddy they are.

* We should document for these mentors how to add things (and remove 
things) from the event's bug list, so that they have some control of the 
experience of their mentees.

* If we have more projects than mentors, it seems fine if we also have 
mentors willing to champion more than one project.

* It would probably be helpful if we make a list of which projects are 
being "championed" by whom. Perhaps on the OpenHatch wiki, on a page 
mostly intended for staffers, so they can use it as a reference when 
someone wanders by and says, "I want to work on something in Ruby" and 
then a staffer can point them at the person mentoring the most 
Ruby-related project.

Those are my thoughts, as I'm writing up a bunch of descriptions for a 
bunch of bugs in a bunch of projects for tomorrow's event at Indiana 
University Bloomington.

We might not implement them literally in the next 24 hours, but anyway 
thought I'd share them before I lost them.

-- Asheesh.