An Open Letter to the Open Source Community

[Peter Whittaker]

On Wed, 2007-30-05 at 14:20 +0100, Matt Zimmerman wrote:
> On Wed, May 30, 2007 at 09:13:02AM -0400, Peter Whittaker wrote:
> > Long email. Summary: The CoC is sufficient as it stands, because of four
> > key words. Be considerate. Be respectful.
> 
> The trouble is that while their application to this situation may be obvious
> to you and me, this isn't universally true.

I both agree with the last point, but not the initial premise: The
application of the CoC is not necessarily obvious... ...and that's a
good thing!

If reflection and introspection - and the occasional courteous reminder
from other members of the community - are required, then we have good
guidelines.

If the guidelines are so clear as to never require interpretation or
introspection or discussion and reminder, than we end up being far too
rule based, and we settle disputes with reference to what is written
rather than continued open discussion. Or at least that's the danger I
think we should strive to avoid by avoiding making changes to the CoC
unless we reach consensus that there is absolutely no other way.

But no amount of rule making - and only "far too many" specific examples
-  will make general applicability clear to all comers.

When the CoC is violated, I believe the best approach is discussion and
courteous reminder/education.

> The CoC... offers... examples... to clarify its intent, such as
> [when not to upload big chunks of code]
> 
> What I'm suggesting is that it might be valuable to provide a similarly
> specific example affirming that discrimination is not respectful, and that
> it creates an environment where people feel (in the words of the CoC)
> "uncomfortable or threatened".

I disagree, as should be obvious by now. In fact, in the interests of
perfect consistency, were a change to be made to the CoC, I would
suggest it be the removal of that example.

The example applies to coders and uploaders, who, while a major part of
the community, are not the whole community. It's an example that, for
some of us, means little.

And it is also something that is explained in greater detail in the
contribution guidelines that have developed over time. Those guidelines
are the right place for such statements. Not the CoC.

As a policy wonk (one of my day jobs), I would argue that most of the
CoC is "good policy", but that that specific example is "practice
documentation" or "procedure". It is consistent with the policy but has
no place in the policy. It's place is domain-specific supporting
documentation.

And to play devil's advocate, the specific example you suggest would
have to be carefully and cleverly crafted, because discrimination is not
a bad thing. We discriminate all the time. It can be a very good thing,
especially when making choices that affect others, to be discriminating
in one's approach. That is, to apply one's critical faculties
effectively and make appropriate choices.

Yes, I know what you mean. But you know what I mean as well. And that
pedantic semantic difference is at the heart of my concern about adding
examples or clarifying text to the CoC: It isn't "discrimination" we are
concerned with, but sexual discrimination, racial discrimination, etc.

Shall we list them all? Or shall we try to work at a high level, and
courteously draw the attention of those who deliberately or
inadvertently violate the Coc back to the CoC and educate them?

Obviously, I prefer the latter. It's more work for all of us, but, in
the end, I think it's a better way of building and maintaining a
community.

pww

ps	FWIW, consider the difference between architecture and
	implementation. The CoC is "big block" architecture.
	The example cited above is somewhere between language
	choice and data structure specifics. If the structure
	or language isn't specified in the architecture, then
	code can be refactored without affecting the behaviour
	or validity of the architecture. But if it is, one has
	to wonder why it is. It's like having the client specify
	a language of implementation as part of the business
	requirements. It's almost never the right thing to do.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/sounder/attachments/20070531/57facfff/attachment.pgp