[TOS] Meeting to discuss HFOSS bootcamp / POSSE
ralph.morelli at trincoll.edu
Fri Mar 5 12:52:48 UTC 2010
Mel and Greg,
Thanks for the suggestions. Of course, you're right about the "learning the
tools" and "learning the culture" distinction. I think we can probably do a
decent job of the former during the 3-day workshop but not the latter.
Especially since we are relative newbies at this and haven't really been
fully immersed ourselves. Trishan and I have had intermittent episodes of
that kind of immersion in our collaboration with Sahana. So I do appreciate
this point and have myself often been "productively lost" --- including when
working on the Sahana IRC. :)
One difference between our 3-day orientation and a POSSE is that for us this
is just the beginning of an 8-10 week, full-time collaboration. So we can
treat the workshop as just the starting point. One thing we plan to do this
summer -- that we haven't tried before -- is using an IRC channel to keep
the whole group together. This is the first summer we will not all be
located at Trinity. So it is necessary that we learn to use the IRC well.
" 'Setting up your own project' will be perilously large" -- Yes, that's
going to be tricky and in one case we don't really have any experience with
what that group will be doing. So it's not clear how we can be supportive.
(Greg: that project is based right in your neighborhood, so perhaps we can
get you engaged?)
On the VCS issue, the different projects use different platforms -- e.g.,
POSIT (Google Code), Sahana (Sourceforge, Trac), OpenMRS (SVN), etc. So
the plan would be to provide a general introduction in the plenary session
plus a brief introduction to their specific repository in the break out
session. But, again, the 3-day meeting will just get them started. They'll
have all summer to gain experience--hopefully with sufficient mentoring and
Regarding collaborators, we'll try to have some in-person collaborators
during the 3-day workshop. During the summer we'll use IRC, email and other
On Thu, Mar 4, 2010 at 5:26 PM, Mel Chua <mel at redhat.com> wrote:
> I like, mostly. Comments inline.
> Same here.
> 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 "tickets" were.)
>>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tos