[TriLUG] CoC beefs

Greg Brown gwbrown1 at gmail.com
Tue Aug 14 11:59:53 EDT 2007


Now that blood pressure appears to be returning back to normal let's get to
the meat of the issue: the CoC itself.

First and foremost if someone who was not a member of TriLUG happened upon
http://www.trilug.org/codeofconduct/ there is no indication that the CoC has
not yet been ratified.  In fact the document says as much: "Because this
Code of Conduct is ratified by the TriLUG membership".  Nothing has been
ratified.

In order to correct that I suggest renaming line one "TriLUG Code of
Conduct" to "Proposed TriLUG Code of Conduct" (or put "DRAFT" on the
document somewhere).

The collaboration section seems unusual to me, perhaps because it is derived
from Ubuntu's CoC.  TriLUG doesn't produce any internal software and while
collaboration is a good thing it is not always possible.  Case in point:
back when Oculan was in existence we produced a product that had within it
both open and closed source code.  If I ask a technical question about, oh,
forking a process in Java am I then supposed to provided my proprietary code
for TriLUG review?  I think it is apparent this is not possible with a great
many products that are in the marketplace.  The proposed CoC doesn't come
right out and address this directly.

Finally, it's a LUG, people argue.  They always have.  I'm not a big
proponent of arguing for the sale of it but people get their feelings hurt
all the time with Open Source, heck I read a couple years ago about some
young man in California that nearly jumped off a bridge because his proposed
kernel patch wasn't accepted.  That's an extreme example, yes, but people
can still debate the merits of OSS X, Y, or Z as adults.  The disagreement
section seems to lean heavily towards a group attempting to create software
via collaborative process.  I'd like to see this section re-written with the
mindset of two people, or a group, bickering back and forth about the merits
of GPL 2 vs GPL 3.  These are the kinds of arguments that I see take place
most often, not argument about implementing function X over function Y
because you feel the software produced by TriLUG will be negatively
impacted.

Big beefs addressed.

Greg



More information about the TriLUG mailing list