[TOS] Meeting to discuss HFOSS bootcamp / POSSE

Mel Chua mel at redhat.com
Thu Mar 4 17:26:57 UTC 2010

> I like, mostly. Comments inline.

Same here.

>> Day 1
>> AM
>> PM
>> FOSS History and Culture
>> Communications tools, practices,
>> etiquette: wiki's IRC, email
>> Instructor:
>> Instructor
>> Networking Activity: Evening BBQ

Looks great - the exercise we used for wikis/IRC works quite well imo 
(coordinating on IRC - no talking! - everyone needs to get a wiki user 
page made. The catch: you can't edit your own page.).

There are two parts to communication: learning to use the tools, and 
learning to swim in the culture. The first one (the exercise I just 
described) may be best in a relatively quiet channel as people get 
familiar with the tools - but at some point, also have them go to a 
hectic, active channel and try to figure out what's going on in the 
multiple threaded conversations of things they have no reference for. 
(Point out that you don't necessarily know everything that's going on 
either - show them how to be productively lost. ;)

The modeling of productive-lostness is very important; making it clear 
that you are effective in FOSS *precisely* because you don't know 
everything and openly admit it can be an odd concept for some.

>> Day 2
>> AM
>> PM
>> Code Management Overview:
>> repositories
>> bug-tracking
>> issue-tracking, etc.. +exercise
>> Breakout Session:
>> Communication/Code management for specific projects
>> Sahana, POSIT, OpenMRS, setting up your own project
> "Setting up your own project" could be perilously large. :) What do you
> mean by this? In the textbook, I assume that this part is "getting the
> code from your chosen project to build on your system." Is that kinda
> what you mean?

+1 to all Greg said.

I worry about this day exploding and hosing everyone. Getting folks to 
grok version control and patches can take up nearly half the day already 
- it's not just a matter of learning syntax, it's also a matter of "wow, 
this is a *totally* different paradigm" sometimes - really depends on 
the experience of the profs coming in.

Also, are you standardizing on one VCS and one ticket-tracker, etc? If 
you go "use the one your project uses" and have some people looking at 
bz, some at trac, some at svn, some at cvs... unless there's a high 
instructor-to-student ratio, the interface details between the two can 
be sufficiently different to confuse newcomers enough that they won't be 
able to grasp the concept of "version control" at large. (I learned this 
the hard way when I was an undergrad trying to teach my friends what 
"tickets" were.)

>> Instructor:
>> Instructor/s:
>> Evening: Working on Exercise?

Make sure the "there will be homework in the evenings" expectation is 
clearly established from the start, and that they have a place (IRC 
channel?) to collaborate in the evenings if not everyone is staying in 
the same hotel.

>> Day 3
>> AM
>> PM
>> Breakout Session II:
>> Exercises and continued orientation for specific projects

This is the point where everyone splits up into separate projects? Does 
any of that happen any earlier?

>> Debriefing: Discussing issues, making plans for follow-up,
>> mentoring, etc.
>> Instructor/s:
>> Evening: Return trips
>> Possible Instructors:
>> Some other ideas:
>> * We would want to recruit mentors/collaborators from the various
>> communities we'll be working with:
>> * OpenMRS( Darius?)
>> * Sahana (Mark Prutsalis, Chamindra?)
>> * POSIT (In house expertise)
>> * GNOME (William Walker?)
>> * We want to include some role in this for the Oregon State folks
>> (Carlos Jensen and Tim Budd)
> Yeah, this sounds essential. What's your sense on how firm these
> commitments are?

Are you focusing on in-person collaborators, remote collaborators (you 
should have some of those to give participants a sense of what it's like 
to work long-distance with useful people ;) and/or both?


More information about the tos mailing list