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

[Norbert Preining]

> For the record, listmaster@ did not moderate you. I'm sorry if you felt
> that you were being unfairly maligned, but this was addressed
> previously:
> https://lists.debian.org/msgid-search/20141201002812.gj25...@teltox.donarmstrong.com

I have been "moderated" by you (AFAIR) in the same way, with implicit threats
using the CoC.  Don't play the "I haven't said anything directly" game.
This *is* moderation, even if you don't see it like that.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

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

[Didier 'OdyX' Raboud]

Le samedi, 4 novembre 2017, 01.39:31 h CET Scott Kitterman a écrit :
> On November 3, 2017 9:09:31 PM EDT, Sam Hartman  wrote:
> > I think that Debian does need a decision making body of last resort.
> > I personally think these communication skills are critical for such a
> > body.
> 
> One critical thing I think the TC misses is to consider if it's time to
> invoke last resort processes or not.  My impression is that if someone
> brings an issue to the TC, there's an assumption that the TC has to deal
> with it.

That's currently quite true; unfortunately. I do think the TC has the moral 
obligation to properly _acknowledge_ all requests filed before it, it should 
really do a better "initial conditions" check.

> The last time I was involved with an issue brought to the TC, it had been
> brought after zero discussion between the person filing the bug and the
> relevant team.  Complaining to the TC about a bug that's been dormant for
> years only a few days after resurrecting discussion about it (AIUI) seems
> similarly aggressive.

Absolutely. During the TC's last IRC meeting [0], we have identified the need 
of a bug-handling checklist, which could do a lot of good there. With such 
(lightweight) formalism in place, the TC would force itself to react to issues 
by first checking if they fulfill some preliminary conditions. Off the top of 
my (tired) head:
* have the maintainers had enough time to interact with the complainant?
* have  efforts to resolve the issue via consensus been tried and failed?
* is the disagreement sufficiently well described?
* etc.

Also, it seems the TC is bound to be focused in the technical problems, and 
how to address these [1], that's just a natural consequence of its name and 
its composition mechanism. Instead of directly addressing the issue, I tend to 
think the TC could instead often start by addressing the "meta" around the 
issue: where, and how is the problem described ? was it debated, and by which 
stakeholders? is the complainant "jumping the gun" or has the discussion 
really reached a point where a formal involvment of the TC makes sense? etc.

> Diving into issues in these kinds of circumstances turns the TC into nothing
> more than a stick to beat other developers with.  I think we need something
> like the TC, but I also think part of being the decider of last resort is
> sticking to the last resort part.

I agree; to some extent. Indeed, for any use of the constitutional powers of 
the TC, it shall really make sure all reasonable venues have been tried and 
failed, as a prerequisite to discussing the technical issue. But there's a 
wide range of issues where it makes sense for TC _members_ to go out and help 
the discussion. We also want people to feel comfortable coming to the TC for 
advice. The fact that the TC uses public bugs also puts some discussions under 
different lights: it's different to have TC members participate in a 
discussion (with or without hats) than have the same conversation on a tech-
ctte bug; a TC bug is (or at least, was) quite likely to end up with a formal 
decision, even if just for closure. The mere prospect of a potential 
maintainer override ad the end of the line is certainly quite offputting; a 
side of the conversation has a finger on the trigger. That leads me to think 
the TC could sometimes close the TC issues (or reassign them) earlier, without 
necessarily stopping the conversation.

> P.S. Having been through a couple of TC issues that involved packages or
> teams relevant to me, I totally get orphaning a package.  I don't know what
> fraction of packages I maintain I care enough about to deal with a TC
> complaint over them, but I'm pretty sure it's way less than half.

That's a quite saddening statement. Could you share (eventually in private) 
for which reasons? In what way could the TC evolve to make you feel 
comfortable having a conversation with it about one of your packages?

With my best regards,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2017/debian-ctte.
2017-10-18-19.01.html
[1] For example, see the start of https://bugs.debian.org/877024
(sorry Keith :-) )

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

[Diane Trout]

> The last time I was involved with an issue brought to the TC, it had
> been brought after zero discussion between the person filing the bug
> and the relevant team.  Complaining to the TC about a bug that's been
> dormant for years only a few days after resurrecting discussion about
> it (AIUI) seems similarly aggressive.

Unless there was some kind of time critical issue, wouldn't it have
been reasonable for the the TC have required a minimum period of
discussion between the involved parties first?

Diane

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

[Diane Trout]

> Steve> Better skills for handling interpersonal conflict can
> never
> Steve> be a bad thing.  However, the Technical Committee exists
> as a
> Steve> decision-making body of last resort, when consensus is not
> Steve> possible (because two parties have incompatible goals, or
> Steve> because discussion is not converging on agreement fast
> enough
> Steve> to matter).
> 
> I think that Debian does need a decision making body of last resort.
> I personally think these communication skills are critical for such a
> body.


I agree. We do need a final decision body.

I was thinking it might help if the TC process helped the people
involved in the issue had a better chance of feeling like their
positions were understood and that hopefully increases the chance they
believe the final decision was fair.

But mostly I was hoping that sharing & discussing conflict resolution
techniques would help us avoid needing to send issues to the TC.

Diane

signature.asc
Description: This is a digitally signed message part

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

[Scott Kitterman]

On November 3, 2017 9:09:31 PM EDT, Sam Hartman  wrote:
>> "Steve" == Steve Langasek  writes:
>
>Steve> Hi Diane,
>Steve> On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote:
>>> 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.
>
>Steve> Better skills for handling interpersonal conflict can never
>   Steve> be a bad thing.  However, the Technical Committee exists as a
>Steve> decision-making body of last resort, when consensus is not
>Steve> possible (because two parties have incompatible goals, or
>   Steve> because discussion is not converging on agreement fast enough
>Steve> to matter).
>
>I think that Debian does need a decision making body of last resort.
>I personally think these communication skills are critical for such a
>body.

One critical thing I think the TC misses is to consider if it's time to invoke 
last resort processes or not.  My impression is that if someone brings an issue 
to the TC, there's an assumption that the TC has to deal with it.

The last time I was involved with an issue brought to the TC, it had been 
brought after zero discussion between the person filing the bug and the 
relevant team.  Complaining to the TC about a bug that's been dormant for years 
only a few days after resurrecting discussion about it (AIUI) seems similarly 
aggressive.

Diving into issues in these kinds of circumstances turns the TC into nothing 
more than a stick to beat other developers with.  I think we need something 
like the TC, but I also think part of being the decider of last resort is 
sticking to the last resort part.

Scott K

P.S. Having been through a couple of TC issues that involved packages or teams 
relevant to me, I totally get orphaning a package.  I don't know what fraction 
of packages I maintain I care enough about to deal with a TC complaint over 
them, but I'm pretty sure it's way less than half.

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

[Sam Hartman]

> "Steve" == Steve Langasek  writes:

Steve> Hi Diane,
Steve> On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote:
>> 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.

Steve> Better skills for handling interpersonal conflict can never
Steve> be a bad thing.  However, the Technical Committee exists as a
Steve> decision-making body of last resort, when consensus is not
Steve> possible (because two parties have incompatible goals, or
Steve> because discussion is not converging on agreement fast enough
Steve> to matter).

I think that Debian does need a decision making body of last resort.
I personally think these communication skills are critical for such a
body.

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

[Steve Langasek]

Hi Diane,

On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote:
> 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.

Better skills for handling interpersonal conflict can never be a bad thing.
However, the Technical Committee exists as a decision-making body of last
resort, when consensus is not possible (because two parties have
incompatible goals, or because discussion is not converging on agreement
fast enough to matter).

Do you believe that Debian should not have such a decision-making body of
last resort?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

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

Thanks again for your mail.
I also trim parts where I think we understand each other and seem to be
in general agreement.
I want to explicitly call out your analysis  of how mailing list
discussions can be problematic.
I think that's a really important point to this discussion.
I might choose to be less formalized in how I'd prefer to solve the
problem.
However I think you've highlighted that mailing list discussions are the
wrong approach for the really thorny issues.

One mechanism that is often helpful in cases where mailing list
discussions add value is to summarize them going forward.
I think we're very close to a point where it would be useful for me to
prepare such a summary of this discussion.

>> 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.

Ian> IMO injustice _itself_ undermines community.

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

Ah, thanks for explaining what you heard.  That's not what i want to say
at all.
Also, I wouldn't even say I put community ahead of justice.  I put
community ahead of technical correctness.  I also think court-style
justice in our community would emphasize technical correctness.  Justice
as an abstract concept is not something I have simple positions on.

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

This statement feels wrong to me.  It's not obvious to me why it is true
that the putting some opinions ahead of others is coupled to making
decisions on the merits.
I think there's possibly more to unpack there, although I'm not sure
it's where we need to go to understand each other.

I'd like to give some examples of cases where I think community  is more
important than technical correctness.

* Some people's opinions do matter more than others on some decisions.
  The most obvious example of this is we have a culture of letting the
  people doing the work have huge latitude.  It might be better overall
  if we picked a single scripting language for all Debian
  infrastructure, maaintainer scripts, development tools, archive
  software and the like.  It's far more important to let the maintainers
  use the tools they prefer.  It might have been great for the project
  to mandate debhelper a while ago.  Just within the last year we've
  finally gotten to a point where policy recommends using debhelper in
  one circumstance.  Again, we strongly prefer letting people doing work
  have flexibility.  So often, the TC finds itself saying "you might
  even be right about the technical issue, but those folks actually
  doing the work get to pick in this instance."

* Sometimes respect for work going on or for process is more important
  than technical correctness.  You and I have disagreed about specific
  instances of the past.  But for example I believe that if the policy
  editors are unsure whether they reached consensus on an issue, one
  significant factor that the TC needs to consider is whether the policy
  team did or did not reach consensus under their internal policies.  I
  understand we disagree on the specifics here, and this is probably the
  wrong forum to rehash that.  I do think that cases where respecting
  what other people are doing and respecting other processes are more
  important to community stability than technical correctness.

* pSometimes it is more important to have maintainers or maintainer teams
  who are good at bringing in new people, mentoring, and the like even
  if it frustrates technical experts.  If a particular maintainer team
  consistently has trouble dealing with their stakeholders, I think
  making changes to improve communication can be appropriate even if  it
  decreases the technical quality of the team for a while.  None of us
  are so good that we cannot be replaced, and yet all our contributions
  are valued.

* Sometimes it is more important to get a decision made than to have the
  perfect decision.  This needs to be balanced against manipulating the
  processes to prevent stakeholders from contributing etc.

* Sometimes the cost of reviewing a decision can be higher than any
  potential gain.  I can think of a number of TC bugs where a lot of
  frustration was spent overriding a maintainer and there was little
  benefit to our users.  It was the 

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 <ijack...@chiark.greenend.org.uk>   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

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

[Ian Jackson]

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by 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.

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

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

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


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

Courts are of course stressful, but I think that stress is usually the
result of the underlying dispute.  (Courts in some jurisdictions are
awful, too, of course, and I'm not suggesting we set up professional
advocates with a vested interest in prolonging and exacerbating
disagreements...)

One big advantage of court-like formality is is that it provides
neutral (and possibly even constructive) ways to express and handle
the disagreement.  And of course it can avoid arguments over the
ground rules.

There are other models: mediation, perhaps.  But mediation is just
facilitated negotiation, and explicitly excludes the question of
justice or rightness.  What really matters for the outcome of
mediation is not who has the best arguments, but what are the parties'
"best alternatives to negotiation".

So the TC should formally adopt rules of procedure, saying how and
when issues should be brought to the TC, and how the TC will handle
them.  The rules should cover questions of when TC members should use
their ability to call for votes, and add amendments.  They should say
what interval is normally appropriate before asking the TC for help.
The rules will need to be bent on occasion, of course - but the rules
themselves should say who can grant permission to bend them.

The TC rules could also limit the email discussion, at least by
default - one of the most exhausting things about the TC right now is
the never-ending email threads.

It would also IMO be a good idea for the TC to explicitly adopt some
"form letters" that should be used in various circumstances.  If there
were a standard TC-approved text for the message saying "I feel
strongly enough about this, and you don't seem to agree, so I think I
will ask the TC for help soon" then that text could be made suitably
collegiate and refined over time, and there would be no arguments
about the tone of someone's email.


> I was not planning on discussing systemd again.

Thanks.  I don't think doing so is going to be illuminating.  It will
just reopen wounds.

Ian.

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Martin Steigerwald  writes:
>> Russ Allbery - 28.10.17, 16:13:

>>> There wasn't *anything* "left out" of that discussion.

>> In my opinion this is a pretty bold statement.

>> If everyone has been heard, noticed, felt and valued, if
>> everything has been covered, then why are we discussing it… yet
>> again now?

Russ> Those are not equivalent statements.  In that sort of
Russ> discussion, it is literally impossible to make everyone feel
Russ> valued, since at least some people on each side will only feel
Russ> valued if their preferred option is chosen.  That's therefore
Russ> not a reasonable thing to attempt to achieve; we can try to
Russ> maximize the number of people who feel valued, but there are
Russ> usually at least some people involved in this large and
Russ> sprawling of a decision for whom "valued" is synonymous with
Russ> "agreed with."

For myself, I've found that if I work with people I can often get to a
point where they feel valued even when there is disagreement.
As you point out that's not true for some people and it is difficult
even when it is possible.

I was not planning on discussing systemd again.

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.
In the limit, I hope to do your literally impossible:-)

Fortunately, I'd be thrilled and filled with joy to simply get closer to
that limit.  Helping create a culture where we have mechanisms to help
ourselves separate value from agreement, and where we value using those
mechanisms would delight me.
I think even that is a hard ask, but I do not think it is literally
impossible.

--Sam

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

[Russ Allbery]

Martin Steigerwald  writes:
> Russ Allbery - 28.10.17, 16:13:

>> There wasn't *anything* "left out" of that discussion.

> In my opinion this is a pretty bold statement.

> If everyone has been heard, noticed, felt and valued, if everything has
> been covered, then why are we discussing it… yet again now?

Those are not equivalent statements.  In that sort of discussion, it is
literally impossible to make everyone feel valued, since at least some
people on each side will only feel valued if their preferred option is
chosen.  That's therefore not a reasonable thing to attempt to achieve; we
can try to maximize the number of people who feel valued, but there are
usually at least some people involved in this large and sprawling of a
decision for whom "valued" is synonymous with "agreed with."

There are two primary reasons why we're continuing to discuss this.  One
is that the decision went a direction that a lot of people didn't, and
don't, like, and they're still unhappy about it.  There's really nothing
that can be done about this; any other decision would have had exactly the
same consequence, just with a different set of people.

The second is that there is a very strong tendency for humans to confuse
"you have heard and fully understand everything I said and simply don't
agree with me" with "you haven't heard me."  I think everyone does this to
some extent.  We're all firmly convinced that our arguments are the best
(since if they weren't, we'd hold a different opinion), and therefore if
someone doesn't agree with us, it must be because they just haven't
*really* heard and understood our arguments.  It's very, *very* hard to
not believe this.  And a *ton* of that happened, and continues to happen,
with systemd.

But... it's just not true.

I'm quite confident that everyone on the TC who made the systemd
discussion fully understood the arguments for the opposing side.  We
simply didn't agree.  And we have to find some way, as project members and
as human beings, to accept that and live with it.  Part of living with it
is not trying to come up with *yet another* phrasing of the argument that,
this time, the other side will *finally* understand.

This phenomenon is not at all unique to Debian.  It happens in all
political discussions.

> I certainly think that the CTTE process can be improved upon. Is it bad?
> I do not know and does it really matter to decide? I am sure everyone
> involved is doing their best. We always do.

> Can it be improved upon? Yes, is my answer.

I'm certainly happy to agree with this!  There's hardly any human process
that can't be improved upon.

My key point here is that if you think there was some other way that the
systemd discussion could have been held, some additional work that could
have been done, such that everyone would have been happy with the
outcome... well, sadly, I just don't think that was on the table.

There are certainly things we could have done better, mechanically,
culturally, interpersonally.  But there was no *argument* left out of that
discussion that would have convinced people, and there was zero chance
that we weren't going to come out of that decision with some very upset
and angry project members.

> Does the everyone involved with CTTE process drive conflict resolution
> processes to their completion?

I don't think the type of conclusion that you're talking about here (I
sense that you're talking about something other than a mechanical
conclusion of a defined process) is something that exists with truly hard
decisions.  This feels like an argument for always making decisions by
consensus, and the sad fact of the matter is that some decisions cannot be
made by consensus because there is no consensus and *will never be a
consensus*.

In those situations, in practice, this line of argument is an argument for
not making a decision, by perpetually postponing the decision because the
conflict resolution hasn't completed, because some people are still
unhappy.  And not making a decision is itself a decision, often a rather
bad one.

The other point I want to make here is that the systemd discussion was one
of the most exhausting and time-consuming things that I've ever been
involved in.  I'm sure some people in that discussion didn't feel listened
to for various reasons, and maybe in a few cases that was because they
truly weren't listened to.  (Perhaps because they were making other
versions of the same arguments other people were making.)  But at least
speaking for myself, there was not the *capacity*, emotional or temporal,
to engage in more detailed personal discussions with yet more people to
make sure they felt fully heard.  This is some of the "being human" part
that I was talking about in my other message.  Making people heard can be
incredibly time-consuming and can require a ton of emotional energy, and
TC members, like all project members, are volunteers.  Often with very
limited quantities of time they can spend on 

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

[Martin Steigerwald]

Dear Russ, dear Sam, dear people involved with Debian,

Russ Allbery - 28.10.17, 16:13:
> Martin Steigerwald  writes:
> > I always found that just focusing on the technical aspects of the Init
> > system discussion left out… everything else. Even the issue in itself
> > was not purely technical, although back then I had the a feeling that
> > almost no one agreed with me that it was not. Just focusing on purely
> > technical means in that discussion was in my eyes harmful in itself.
> 
> Well, I agreed, and agree, with you that the issue was not purely
> technical, and spent a substantial amount of time, effort, and writeup
> energy on discussing the non-technical issues.  Your description bears
> very little resemblence to the process I was part of.

As always perceptions of different people are different…

> I think it's really important to not oversimplify past discussions.  We're
> in danger of learning the wrong lessons from them.
> 
> One of the reasons why the systemd discussion was so painful was precisely
> that it could *not* be discussed at a level of purely technical details,
> and we all knew it.  […]

My impression from what I read of the discussion was exactly as I described… 
so I did not simplify it by conscious choice…

however I do not claim having read all of it. I also do not claim to remember 
all that I read. It was a *ton* of mails back then and at one point there was 
what I received as moderation but apparently was not meant as one by Don, and 
I decided I could not bear this any longer. I decided to let go of it as best 
as I can. I did not read any of the mails past that point in time.

So yes, I may have simplified it.

> There wasn't *anything* "left out" of that discussion.

In my opinion this is a pretty bold statement.

If everyone has been heard, noticed, felt and valued, if everything has been 
covered, then why are we discussing it… yet again now?

If the conflict resolution process proceeded to its completion, there is no 
reason to.

Moving in circles, as I had the impression the discussion moved in back then 
is not proceeding to its completion. Its the attribute of a circle that I can 
walk its outline forever especially when I do not notice that I am doing so.

So is it merely me wanting badly to have a problem again – or Sam wanting to? 
Or, is there still something left to be noticed, welcomed, embraced and let go 
of? Is there still something that you, understandably, deny by not wanting to 
have that problem again? Only you can answer that question by noticing what 
you feel, so I don´t even try to. Also its not only a question you can choose 
to ask, but one everyone can choose to ask, including myself.

Each one of us can do this work on his or her own. And I am certainly willing 
to.

I certainly think that the CTTE process can be improved upon. Is it bad? I do 
not know and does it really matter to decide? I am sure everyone involved is 
doing their best. We always do.

Can it be improved upon? Yes, is my answer.

I trust to find the answer as to how within me. I may share it when I find it 
at a later time, if its still important to share it then.

One part of an answer for me is within the question I asked here implicitly:

Does the everyone involved with CTTE process drive conflict resolution 
processes to their completion?

Or does someone or a group of people decide to prematurely stop it cause they, 
again, understandably, can not bear it anymore and want to get rid of it? If 
so, what change in how I see a conflict can help me to move beyond?

And can I let go whether moving beyond would be superhuman or not? What is 
human anyway? Am I my human experience?

I let go of any desire to change things now as I just catched myself of 
holding onto it. In the end I am still with the Debian project. I just did a 
new version of fio package. And I keep myself somewhat informed about what 
people do in the Devuan project as well. So what happens if I just accept 
things as they are, just for now?

Thanks,
-- 
Martin

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

[Russ Allbery]

Gunnar Wolf  writes:

> It's easy to reach a technically sound decision, but it's hard to uphold
> it without someone somehow getting sore about it. I don't know how
> inevitable this is, but I recognize it happens in many different
> areas. And a few sore people "hurt" more than a silently sympathetic big
> crowd.

I think there are several principles that I suspect most people bring to
TC decisions.  Certainly, I did.  I think it may be helpful to look at
them and realize that they're *inherently* in conflict.  In other words,
it's clearly possible to find cases (and we have found cases) where it is
literally impossible to satisfy all those principles at the same time.

Off the top of my head:

1. Make timely decisions so that tense situations that are causing social
   and technical friction are resolved as quickly as possible.

2. Ensure that every party in the conflict is completely heard and
   understood before making a decision.

3. Avoid forcing people who are already burned out on a problem to do
   *significant* emotional and mental work to write up their positions,
   arguments, rebuttals, and defenses.  I cannot overstress just how much
   energy and time this requires to do properly, particularly for
   volunteers.  Being a party to a TC bug can easily start to feel like
   you need to take time off work to respond properly.

4. Make a decision in a way that doesn't drive any party away from Debian
   (on either side of the conflict).

5. Make the decision that leads to the most technically correct
   distribution and the best and most usable result for our users.

6. Avoid letting someone's heartfelt unhappiness not force an incorrect
   decision when they are (however sincerely) in the wrong (either
   socially or technically or both).

7. Be transparent to the rest of the project and available and responsive
   for questions from other project members who have concerns about the
   process or outcome.

8. Make a decision that upholds the aspirational, ideological, and ethical
   standards of the project.

If one thinks through all the ways in which these principles can come into
direct and painful conflict, I think it becomes clearer just why this can
be so hard.

I think it's also worth remembering that *every* community finds this
hard.  I think it's safe to say that every legal system, appellate
process, or conflict resolution mechanism known to humans fails at one or
more of those principles much of the time.

We should always try to do better.

We should avoid expecting ourselves to be superhuman.

-- 
Russ Allbery (r...@debian.org)   

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

[Russ Allbery]

Martin Steigerwald  writes:

> I always found that just focusing on the technical aspects of the Init
> system discussion left out… everything else. Even the issue in itself
> was not purely technical, although back then I had the a feeling that
> almost no one agreed with me that it was not. Just focusing on purely
> technical means in that discussion was in my eyes harmful in itself.

Well, I agreed, and agree, with you that the issue was not purely
technical, and spent a substantial amount of time, effort, and writeup
energy on discussing the non-technical issues.  Your description bears
very little resemblence to the process I was part of.

I think it's really important to not oversimplify past discussions.  We're
in danger of learning the wrong lessons from them.

One of the reasons why the systemd discussion was so painful was precisely
that it could *not* be discussed at a level of purely technical details,
and we all knew it.  Technical details are much easier to reach decisions
of fact on; the systemd discussion was painful precisely because it
*wasn't* and *couldn't* be conducted in the way that you describe.  It
touched on everything from competing visions of the nature of free
software in the project, the meaning of our social contract and
"universal" in the motto of our distribution, the attitudes and behavior
of multiple different upstreams, accusations of corporate conflict of
interest, and deep personal friendships.

There wasn't *anything* "left out" of that discussion.

-- 
Russ Allbery (r...@debian.org)   

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

[Don Armstrong]

On Sat, 28 Oct 2017, Martin Steigerwald wrote:
> During posting in those endless mailing list threads back then and
> then being moderated by listmasters… asking myself "why me? … and not
> everyone else as well?"

For the record, listmaster@ did not moderate you. I'm sorry if you felt
that you were being unfairly maligned, but this was addressed
previously:
https://lists.debian.org/msgid-search/20141201002812.gj25...@teltox.donarmstrong.com


-- 
Don Armstrong  https://www.donarmstrong.com

"Old hypotheses never really die, they're like dormant volcanoes."
 -- John McPhee _Annals of the Former World_ p313

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

[Gunnar Wolf]

Sam Hartman dijo [Fri, Oct 27, 2017 at 08:18:48PM -0400]:
> 
> As a member of the technical committee, I've grown increasingly alarmed
> as I think about the impact of the issues that come to us.
> Yes, we're giving answers.  However, I think we are doing a lot of harm
> to the members of our community in the process, and I would like to
> explore whether we can do better.
> 
> I've written a blog entry describing my concerns.  It's on Planet, and
> you can see it at https://hartmans.livejournal.com/97174.html

I read your blog post earlier today, and it left me wanting to come
back to it. I'll take this as the cue to do so :-]

> I've reached a point where I'd like to share my concerns and ask "anyone
> else feel similar?  Anyone else want to work on solving this?"

The problem you point out is (surprise, surprise) a hard and recurring
one. I cannot look at it from the TC perspective, as even though I am
now trying to follow the public discussions in the ctte list, it would
be silly if I didn't admit to occasionally (hey, it's you who
mentioned the init system discussion!) kill whole threads when they go
over the level of detail I am comfortable in dealing with.

I understand your frustration stems from the much more recent (and
swift) issue with modemmanager. I was also surprised with the time it
took to be resolved, but the seeming uneasiness that still comes out
of this. Other than this point, from my (again: Incomplete)
perspective, the CTTE today works amazingly well and frictionless. I
am sure that Debian as a project is way more mature than when I
joined, almost 15 years ago. Makes sense: A good portion of us are
still around, and we have surely matured individually! Newcomers who
join us no longer have to grow thick skins, because that is no longer
the project's identity. Thankfully.

You mention, "our community is more important than technical
correctness". This might be, if any, the recurring lemma for the
period I have been involved in Debian. I feel we are getting much,
much better at it - But human issues are just harder. And, as a CTTE
member, you are subject to be the receiver of much of that
attention. It's easy to reach a technically sound decision, but it's
hard to uphold it without someone somehow getting sore about it. I
don't know how inevitable this is, but I recognize it happens in many
different areas. And a few sore people "hurt" more than a silently
sympathetic big crowd.

I know the domains we work at within the project are quite orthogonal,
and that's why I'm drawing a parallel with what we have done (OK, bad
joke... Anyway...) We did the keyring migration, pushing towards it in
late 2014. We had many people questioning procedures and requirements,
but IIRC only *two* felt we were pushing them aside. The decision was
unequivocally sound technically, but it hurt socially (mainly to those
that were socially or physically disconnected from the "core"). This
year, we had a sort-of-rehash with the set of DD retirement notices
(and corresponding DM retirement actions) we saw since late August. We
saw some interesting, constructive criticism in d-private; DDs can
refer to late September and early October for the related discussion
in debian-private.

And, yes, one or two sore cases will suck a lot of energy and
bandwidth. And will leave a *great* process with few but very
resounding unhappy tones clinging to it.

Anyway — If this serves in any way as motivation, I do hold the CTTE
as a *great* team in the project, and I do look up to you and others
who have volunteered and been selected to be a part of it. I am very
glad it outgrew being "just" a technical decision body and assumed its
social place, as your post shows: Technical and social go hand in
hand, we cannot expect to hold a technical decision without hurting or
empowering some of the involved parties.

So... don't know what else to say. Of course, there are no recipes. We
are just people, we are a bunch of individuals working together on
something we all think is worth our time (and that's as far as "doing
consensually things together" goes). I hope this mail (or whatever
other mails sum up in this thread) helps you feel better a sense of
togetherness and shared purpose again.


signature.asc
Description: PGP signature

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

[Martin Steigerwald]

Hello Sam.

Sam Hartman - 27.10.17, 20:18:
> As a member of the technical committee, I've grown increasingly alarmed
> as I think about the impact of the issues that come to us.
> Yes, we're giving answers.  However, I think we are doing a lot of harm
> to the members of our community in the process, and I would like to
> explore whether we can do better.
> 
> I've written a blog entry describing my concerns.  It's on Planet, and
> you can see it at https://hartmans.livejournal.com/97174.html
>
> 
> I've reached a point where I'd like to share my concerns and ask "anyone
> else feel similar?  Anyone else want to work on solving this?"

Thank you for that.

I always found that just focusing on the technical aspects of the Init system 
discussion left out… everything else. Even the issue in itself was not purely 
technical, although back then I had the a feeling that almost no one agreed 
with me that it was not. Just focusing on purely technical means in that 
discussion was in my eyes harmful in itself.

During posting in those endless mailing list threads back then and then being 
moderated by listmasters… asking myself "why me? … and not everyone else as 
well?" I felt so hurt, that I wanted to give up maintaining my few packages. 
So the discussion process itself *even* before involving the Tech-CTTE was 
harmful in my perception.

> In thinking about my concerns I went over a list of issues that have
> come before the TC going back somewhat before the Systemd discussion.
> However, I did not perform any quantitative or statistical analysis.

Do you think decisions of the Tech-CTTE or the process around it changed 
significantly during the Init system decision process? I can imagine that this 
debate back then left a lot of bitterness in quite some of the people who 
engaged with it and I would not be surprised that the decision processes after 
this debate more easily turned into fierce battles than before.

I know the one of the most important ingredients to heal wounds of the past: 
It is forgiveness. The past… is in the past. I know how challenging it can be 
to let go of it.

> If we get to a point where we want to propose a specific change, we'll
> need to convince the project it will make things better.  That's a ways
> down this road.

I have no firm idea how a change could look like, but I think I have a hunch on 
some important aspects in this:

I think it is important to understand the nature of conflicts in order to move 
beyond. Common responses to conflicts are either fight or flight, or stand 
still 
and hope no one will notice you. These responses can be life saving in death-
or-life conflicts, but are often not beneficial in complex decision processes 
that involve technical, social, ethical and personality aspects like within 
Debian. So an important question is: If I neither fight nor flew away or stand 
still and freeze, what will I be doing then?

I agree with you that an important aspect is that each party receives the 
chance to fully express their own position and be heard, seen, felt and 
valued. So I think there needs to be a shift to see conflicts as something 
positive and provide a safe space to express them.

Challenging for me is the answer to the question: How can such a safe place 
look like in a community that is spread around the globe and can often only 
connect via the means of the internet?

Thanks,
-- 
Martin