Re: My responses to developers' responses

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Mon, Jun 25, 2012 at 03:23:38PM +0200, address@hidden wrote:
>
>> > The arguments are another problem that lessens the feeling of
>> > teamwork.  We should be able to "agree to disagree" -- namely,
>> 
>> I agree, but I have come to realize in the past year that politeness
>> is more linked to someone's capacity to be polite than any inherently
>> good or bad aspect of a patch (meaning that there is no such thing as
>> a patch that merits more or less politeness, just people who are more
>> or less polite by nature).
>
> I agree that there's no such thing as a patch that merits more or
> less politeness, but I disagree that politeness is linked to
> someone's capacity to be polite.

Let's say that there is correlation.

> There's all sorts of tricks one
> can use to be more polite (particularly by email):
> - after writing an email, wait at least 2 hours, then re-read it
>   and look for any problems
> - try to imagine how you would react if you received such an email

Nobody sends me the kind of Emails I write myself, so I have no hard
data for that.

> - if you really never take any emails personally, then just try to
>   remember how other people reacted when receiving similar emails
>   in the past.  Look for words or phrases that triggered big
>   arguments in the past, and reword those sections.
>
> Some people may be naturally polite (I can't make educated guesses
> about this), while other people might need to "work" at being
> polite.  In the latter case, the key is *wanting* to be polite, of
> *wanting* to work together, of *wanting* to not drive away
> existing developers.

The problem is that mailing lists are a medium conveying messages, not
humans.  So one tends to argue with messages, not with humans.  The only
human in the argument is oneself, and there is no reason not to blast a
message when it interferes with the only human one can reliably feel
involved in the argument.

I have had the experience that actually meeting the people behind the
messages helps.  I have, on rare occasions, sent an Email in private to
persons (both those I met in person and not) I respect and who are in
some respect similar to myself, and who just digged themselves in the
kind of communication hole I find myself in semi-permanently,
essentially telling them "Damage control here.  What you are currently
doing is not leading anywhere good.  Better back off and apologize
before it gets worse."  Much to my surprise, the reaction to such a
suggestion without exception has been following it.  Promptly, no
question asked.  Depending on the situation and medium, either with
personal contact or in the medium where the problem occured.

This sort of emergency advice does not work in public.  I have no idea
whether it would stand a chance working with the frequency I myself
might be in need of such advice.

If people go off the bad end, telling them publicly will tend to put
them more in the line of fire (and make them react accordingly) rather
than giving them an opportunity to reflect and step out.

> The potentially-nice thing about email is that there's no voice
> inflection or face images.  It's really easy to "act" in writing.

It may be for you.  My behavior is sort of under a "thou shalt not lie"
curse.  It drives some people crazy how often they will get evasive
answers from me in order to save myself from committing to some absolute
statement.

> I'm fairly confident that if we approached email messages the way that
> people approached letters 200 years ago, we could avoid some problems.

With one of my best friends I settled on me never writing him a letter
again, ever.

Go figure.

At any rate, we can't have an atmosphere where people don't enjoy
contributing to LilyPond.  I focus on making it enjoyable working with
the LilyPond program, but this is pointless if I manage making it not
enjoyable working with the LilyPond developers.  And if the people with
good communication skills "make room" for the people with good coding
skills and leave, the project not only dies, but also loses hope for
revival.

And this won't do.  I don't see that we can get this under control using
policies.  It requires those who _have_ skills and talents in that area
to do their part in helping those who don't keep from damaging the
project.

Of course, it is nobody's duty, and not necessarily fun, but like many
other participations in a project, it is a teamwork effort that not
necessarily is distributed equally, but according to skill sets.

-- 
David Kastrup