[TOS] Meeting to discuss HFOSS bootcamp / POSSE
mel at redhat.com
Thu Mar 4 17:26:57 UTC 2010
> I like, mostly. Comments inline.
>> Day 1
>> FOSS History and Culture
>> Communications tools, practices,
>> etiquette: wiki's IRC, email
>> 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
>> Code Management Overview:
>> 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
>> 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
>> 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.
>> 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