Re: [PATCH] Documentation/CommunityGuidelines

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jun 11, 2013, 04:41 UTC
Message-ID: <51B6AA7F.1060505@alum.mit.edu>
In-Reply-To: <CALkWK0mqk5sRPV8PHz8RqZH-Ln7TUtkHPVbvsJPKuVSXiUOiww@mail.gmail.com>

On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:

> I've tried to write down a bare minimum, without restating the obvious.

Thank you for drafting a proposed CommunityGuidelines document; I think such a document would be helpful. But I don't like the overall flavor of your proposal; frankly, it sounds to me more like

Documentation/GuidelinesForCommunityToBendOverBackwardsToLiveWithFCsProvocations

and I don't think that is healthy.

> 0. You do not take offense, no matter what.  If someone attacks you
> irrationally, you do not respond.  This is a public mailing list, and
> we are all rational people: the attacker has already humiliated
> herself in public, and everyone can see that.

This is secondary to the more important rule, "do not attack other people on the mailing list". Not taking offense is at best a(n important) fallback position for those regrettable occasions when somebody else has already violated the primary guideline.

Show 10 quoted lines

> 1. You do not take sides or vote.  Do not post emails under the
> pretext of agreement: repeating what has already been said does not
> strengthen the argument.  Post only if you have something unique to
> add to the discussion.
> 
> 2. You stop pointing fingers.  Every heated discussion requires more
> than one participant, and a flamewar requires many participants.  If
> you participate, you have implicitly agreed to share the blame for
> whatever happens on the thread.  People can judge for themselves who
> is to blame.

Here your wording "every heated discussion requires more than one participant" seems to put more of the blame for heated discussions on participants 2..N and give a pass to participant number one.

> 3. Thou shalt not commit logical fallacies.  The ones that are most
> common on this list: strawman, ad hominem, burden of proof, false
> cause, the texas sharpshooter, and appeal to authority.

I think putting a rule like this in CommunityGuidelines puts too much weight on it. In my recollection, pointing out other people's supposed logical fallacies is far more often used on this list as a nitpicking diversionary tactic that usually leads a conversation *further* away from the real issues. I think it would be a mistake to encourage such formal and stylized argument on the ML.

Show 5 quoted lines

> 4. Lead by example.  If you do not like how someone presents
> themselves on the list, you counter it by presenting yourself nicely
> on the list.  Others will follow your example, making that person's
> behavior the minority.  It is far more powerful than explicitly
> stating what is "acceptable" behavior and what is not.

Leading by example is a great approach, and has the effect that you describe on the majority of people. But I also think it would be helpful for the community to agree on a few very minimum standards of behavior that we insist on, and to call people out (preferably in a private email) if they fall short of these standards.

Show 8 quoted lines

> 5. We are a community of programmers, and we are here to collaborate
> on code.  The argument that leads to higher efficiency and better code
> has an automatic advantage over the argument that doesn't.
> 
> If someone breaks one of these rules, there's a very simple way to
> communicate this to them: you don't respond to their email.
> Optionally, respond to their email off-list calmly explaining what
> went wrong.

I would prefer a community standards document that looks more like this:

* Treat other community members with courteousness and respect.

* Conduct disagreements on a technical, not a personal, level.  It is
unacceptable to attack another community member personally, even by
insinuation.

* Keep in mind that email is a medium prone to misunderstandings, and
that many mailing list participants do not speak English as their first
language.  Interpret other people's emails charitably.  If you are not
sure that you understand, ask for clarification.  Assume good intentions
on the part of others, and do not attribute technical disagreements to
ulterior motives.  Choose your words carefully to help other people
avoid misinterpreting them, and avoid hyperbole.

* Strive to keep the mailing list a forum for effective collaboration.
Only post if you have something worthwhile to add to the discussion.  Be
concise and do not repeat what has already been said.  Code reviews,
contributions of patches, and concrete data such as bug reports are far
preferable to philosophizing, vague suggestions, and whining.  Avoid
bikeshedding and do not participate in flame wars.  Avoid revisiting
settled debates unless the facts have changed.

* Accept reviewers' comments gratefully and take them very seriously.
Show that you appreciate the help by giving the reviewer the benefit of
the doubt.  If, after careful consideration, you find that you cannot
agree with a reviewer's suggestion, explain your reasoning carefully
without taking or giving offense, and seek compromise.

* When reviewing other peoples' code, be tactful and constructive.  Set
high expectations, but do what you can to help the submitter achieve
them.  Don't demand changes based only on your personal preferences.
Don't let the perfect be the enemy of the good.

* Be welcoming to new community participants.  Help them get oriented,
and be patient with their questions.  Gently introduce them to our
community standards, above all by setting a good example yourself.

* It is not OK to use these guidelines as a stick with which to beat
supposed violators.  However, if you genuinely feel that another
community member is routinely behaving in ways that are detrimental to
the community, it might help to calmly express your concerns to that
person, preferably in a private email, and naming concrete and specific
incidents rather than broad generalizations.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/