Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Diane Trout]

Hi,

I only just subscribed and only have read some of the discussion so
this may be a bit off topic or already discussed.

But I was wondering if the project has thought about explicitly
encouraging mentoring in techniques for handling interpersonal conflict
and helping members develop interpersonal skills? 

I know there's active research into managing team conflict, and I bet
there are some Debian members who have been more effective at helping
other team members that we might be able to learn from. 

I know we have methods to share technical skills via policies and best
practices, but how do we identify and share useful social techniques?

For instance I think active listening is a useful technique when trying
to develop a consensus about a topic.

(e.g. http://ggia.berkeley.edu/practice/active_listening#data-tab-how )

But I don't know how many others know about it and there would need to
be some adjustment for a distributed team like Debian.

Diane

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Ian Jackson]

Thanks for your mail.  I have trimmed vigorously the parts I agreed
with :-).

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: 
Concerns about the Technical Committee"):
> That said, I actually think in some cases we need to spend more energy
> rather than less.  Minimizing energy spent on the process is not one of
> my goals.  I think that the TC in particular may need to spend more
> energy to have a chance of people feeling valued even when there is
> disagreement.

That may be true.  I think perhaps what I mean is that we are not
spending our energy well.

Unstructured mailing list discussions work reasonably well when
everyone feels that everyone else is on the same side, and everyone is
trying to understand the issues and feel they will be able to come to
a consensus, or at least a conclusion that everyone finds tolerable.

When things get more difficult, they become sprawling horrors.
Participants (quite understandably) feel the need to respond to
everything their now-opponents say.  People feel under time pressure.
It becomes difficult to see the wood for the trees.  Because the
parties are replying directly to each others' emails, there is ample
opportunity for misunderstanding, and all the escalations of minor
aggressions or poor word choices etc. into meta-disputes and anger.

I think it would be better if we asked participants to write a much
smaller number of longer and more comprehensive statements.  The TC
would have to explicitly forbid the use of the email-thread-based
debate style, even as a supplement (perhaps, by blocking it from the
TC's list).  If after however many (small number of) rounds of
refinement/response are permitted, one party decides they need to add
something to their statement of their case, they should have to ask
permission.


> Interestingly, the one area where I think conserving energy is important
> is the one you call out: minimizing the energy people need to spend
> responding to a complaint.
> Even there, I think that in a case where the TC thinks it is likely to
> ask a maintainer to make a change (or override the maintainer) it is
> reasonable to expect the maintainer/respondant to spend enough time to
> explain their position well enough that the TC understands it.

Yes, I absolutely agree.  But I think your suggestion that the TC
should evaluate an incoming complaint, to see if there is a case to
answer, before expecting anything from the maintainer, would be very
helpful.


> I also think the court emphasis on justice and "right" is harmful.  As I
> said in my blog entry, technical correctness is an important factor, but
> I think it is a less important factor than maintaining our community.

IMO injustice _itself_ undermines community.

When you say you want to put "community" ahead of "justice", what I
hear is that you want to put the opinions of some people ahead of
others, because they might be hurt more if the decision goes against
them, or because the are more important to the project somehow.

After all, if we are not to put some people's opinions ahead of
others, what we are left with is making decisions based on the merits,
which is what I am thinking of as justice.

That's not to say that we should not try to maintain our community.
Certainly we should try to reduce the damage done by disputes.

And "merits" does not usually mean technical merits.  Normally it
means thinking about whose interests are more vitally at stake.  It
often means thinking about those for whom the status quo is least
tolerable.


> However, because of who we are, we tend to emphasize technical
> correctness.

I agree with you on this part though.  It is very rare that a dipute
before the TC is mostly technical (let alone entirely technical).

The things people are usually arguing about are:

* Tradeffs between the interests of users with different use cases.

* Whose job is it to do some work that people think is desirable - or
to put it another way, who will bear the pain of the fact that the
work has not yet been done.

* Who is allowed and required to review (and, ultimately, if they see
it as necessary, block) others' work.

* To what extent must a maintainer permit contributions (and,
therefore, maybe to carry patches) that others care about, but which
the maintainers feel are not worthwhile (or even, inappropriate).

These are all, ultimately, questions of politics: they concern the
balance of competing interests, and the location and scope of power
and control.


Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by
Ian> Disagreement: Concerns about the Technical Committee"):
>> I am discussing how we handle conflict because I hope we can do a
>> better job of helping people feel valued even when we do not
>> agree with their technical positions.

Ian> You've perhaps heard me say this before, but I think the TC
Ian> process lacks structure and that if the TC set out the process
Ian> more formally, things might go less awry.  (And also it would
Ian> involve less of an investment of energy by all the partipants,
Ian> particularly the respondents to a complaint.)

I thank you for presenting this again.  This time, you focused more on
what you were hoping for out of the proposal rather than on your
preferred details, and I got a lot more out of it.  It's easier for me
to start out thinking about goals, and you spent more time (or at least
I spent more time reading) about your goals in this version.

Ian> One of the most toxic things that can happen in any kind of
Ian> dispute is for there not to be a clear understanding of what
Ian> the rules are, within which the dispute will be conducted.  Ie,
Ian> who is allowed to do and say what, and when.

I think it would be quite valuable for the TC to spend some time
documenting what people can expect.
I think it would be valuable to spend a lot of time thinking about how
we can avoid the need for a defensive reaction from people responding to
a complaint.

That said, I actually think in some cases we need to spend more energy
rather than less.  Minimizing energy spent on the process is not one of
my goals.  I think that the TC in particular may need to spend more
energy to have a chance of people feeling valued even when there is
disagreement.

Interestingly, the one area where I think conserving energy is important
is the one you call out: minimizing the energy people need to spend
responding to a complaint.
Even there, I think that in a case where the TC thinks it is likely to
ask a maintainer to make a change (or override the maintainer) it is
reasonable to expect the maintainer/respondant to spend enough time to
explain their position well enough that the TC understands it.


Ian> When people disagree about the metarules, community
Ian> disintegrates because people feel that not only are their
Ian> opponents disregarding their needs, but they are also playing
Ian> foul.

Yes.


Ian> I know that some people disagree, but I think that the TC
Ian> should take on much more of the trappings of other formal
Ian> dispute resolution mechanisms that we find in wider society.
Ian> Particularly, the TC should be more like a civil court or
Ian> tribunal.

Ian> Courts are of course stressful, but I think that stress is
Ian> usually the result of the underlying dispute.

There's a time in my life where I would have been in complete agreement
with you.

I've spent enough time working with dispute resolution processes that
work like courts or tribunals to have high confidence they wouldn't work
better than what we have.


As a distant third-party observer, I  can look at a court transcript and
have a positive reaction.  It's fair and just.  All sides were
considered.

However, like in our process, courts do not optimize for the
participants feeling valued, for the participants feeling their concerns
were considered.  I feel concerned thinking about us moving closer to a
court process, because I don't think it would address the concerns that
led to me writing this thread.  I think that people would be very likely
to walk away from the process hurt and less likely to stay in our
community.

I also think the court emphasis on justice and "right" is harmful.  As I
said in my blog entry, technical correctness is an important factor, but
I think it is a less important factor than maintaining our community.
However, because of who we are, we tend to emphasize technical
correctness.  I think that our natural tendencies plus a court/tribunal
process would be a very bad combination in terms of compassion for our
community.

I do appreciate you taking the time to share your desire for clearly
defined expectations for what people can expect in the process.
I hope the project can do that for us both.


--Sam