My comments, in brief:
- how to do this efficiently with limited time resources.
Always a challenge.
- which topic have priority over the next, sequencial processes are not always the more friendly. (i.e. requesting a features is faster than building/debugging).
Communication. Communication, communication. Distributed communication and the etiquette and cultural norms of FOSS communities as contrasted to academia are HUGE. I and others here can point you towards papers on the topic if you're interested. (We really ought to make more of these papers open access.)
If the only thing they get from the workshop is how to communicate, THAT'S GOOD. (and from prior experience, you'll likely need most if not all of the time for that.) That gives people the ability to continue learning in the future when they go back home.
(This is my highly biased opinion; POSSE alumni may have other things to say.)
- Disrupting a community with a false sense of commitment. (or try to encapsulate the 'community experience' avoiding the real community)
Handled correctly, faculty can be a *huge* asset for this -- having a random newbie waltz in and say "can I do X?" vs knowing that these students are coming in as part of a well-scaffolded course led by a faculty member... there's a lot more guarantee that a university course will at least stick around, complete the semester, consistently try to do useful things. The class *is* running that semester, after all.
- Interact on IRC with some developers and communicate on mailing lists
http://teachingopensource.org/index.php/IRC_and_wiki_introduction_exercise may be useful.
_______________________________________________ tos mailing list [email protected] http://lists.teachingopensource.org/mailman/listinfo/tos
