Hi all, This is not meant to be tongue-in-cheek, nor is it critical of MJ Ray's comments. I personally think this serves as a wonderful highlight of something that students engaging in open projects will likely encounter and, potentially, be unprepared for. David H., Chris T. or others who have spent substantial time throwing students into the *OSS space will know better than I.
On Sun, Sep 6, 2009 at 13:15, MJ Ray<[email protected]> wrote: > Greg DeKoenigsberg <[email protected]> wrote: [...] > and if the current exclusive approach prevails, the book will have to > be forked to be useful to my groups anyway. Should there be an appendix on "holy wars" and zealotry in the world of open-source projects? This is something that students coming into open projects may not be ready for: the fact that someone, at the start of a process, might be willing (or even eager) to walk away from the group's work over definitions and terminology, the choice of programming language, and so on. Each community has their own standards for discourse and contribution, and requires you to be more or less fireproof. The Scheme community, for example, requires kevlar-plated asbestos on a good day. ;) What strategies do you use to placate/include/encourage/support differing points of view over what are typically considered the topics of holy wars? (I'm over-simplifying; please don't take this as a point to mince words...) For example, MJ has just suggested that if his POV is not honored, he'll walk away from this particular project, and perhaps fork it later to suit his own needs. At the end of the day, this is actually a fundamental part of the open culture: you can fork it and have your own sandbox to play in. Some projects don't have clear guidelines about participation and inclusion, while others do: for example, I have always liked the Subversion team's approach: your name is never in the code, so if you submit work and insist on individual attribution in the source, we'll throw away your patch. (I think I'm remembering that correctly.) This clear, simple project guideline gives the team a way to enforce that contributors check their ego at the door, and makes it clear what one fundamental rule is for playing in their sandbox. There's a half-dozen different directions these kinds of conversations can go, and being prepared for deeply held beliefs and religion in this space is part of the game. Does the text address it anywhere (it shouldn't be in the introduction), and would this be a welcome contribution that may, or may not, find its way into an appendix of sorts? Cheers, Matt _______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
