Dispute resolution in Debian

2020-07-26 Thread Felix Lechner
Dear Technical Committee,

In deviation from community standards, I top-post. I hope it provides
a simple and coherent narrative that is also compelling. You should be
familiar with the issues raised in Sean's email.

I would model access to conflict resolution on the US courts. There
should be two levels of jurisprudence: One is quick and easily like
small claims, the other is for appeals. Both can issue rulings that
bind everyone, including delegates and the DPL.

Private side conversations should remain off-limits. They create an
incurable attack surface that lowers credibility. Decision makers who
expressed an opinion outside the official process must recuse
themselves. To seek their opinion, please file a case.

As Sean wrote, many problems at Debian are social in nature, I would
make the Community Team the first legal instance before a party can
appeal to the Technical Committee. Cases at Community Team level
should be heard before a single member unless someone requests a
hearing en banc. That effectively makes the Technical Committee
Debian's Supreme Court (which hears all cases). In some way, this
resembles Sean's Proposal 2.

Like any court, the Community Team and Technical Committee should be
able provide independent solutions of their own design. Ideally, the
judges at the lower level, i.e. the Community Team, would be elected.

Thank you for your hard work on the Technical Committee!

Kind regards
Felix Lechner

-- Forwarded message -
From: Sean Whitton 
Date: Sun, Jul 26, 2020 at 1:37 PM
Subject: CTTE requesting questions for DebConf20 BoF
To: 


Hello everyone,

...

The technical committee has served the project for many years, acting as
a conflict resolution body of last resort.  The TC is established in the
Debian Constitution,[2] which means that it's a highly regulated body
and it's hard to change it. The current setup of the TC has several
problems that need to be addressed.

This document is split between first a description of the current
situation and the problems identified, followed by a bunch of different
proposals that we could implement to try to solve said problems.

Problems


Perception
--

Because everything is mandated to be public, discussions must take place
in a public forum where anybody can jump in and add wood to the
fire. This can be very taxing, so there are community members that just
check out and refuse to participate in the discussion even when their
input would be valuable. And even those who participate can feel that
their voice is being drowned by whoever sends the most emails. The
committee strives to hear all opinions equally regardless of how many
emails were sent, but the participants of the discussion can still end
up with a bitter taste because of how it devolved.

Going to the TC is seen as a nuclear option, as a stick to beat others
with.  This is partly because of how the Constitution establishes that
the role of the committee if to be a last resort decision maker. But
also because of historical reasons that are very hard to change, even
when the committee members have all changed by now.

People don't like being on the "losing" side of a decision, but even if
they are on the "winning" side of it, lots of people don't want the
level of flamewar and attention that an issue raised to the TC
brings. Some people would rather orphan a package than participate in a
discussion with the TC.

Social vs Technical
---

Most of the problems that reach the TC are not purely technical. There's
a lot of "human stuff" going on. People with different goals or
interests that fail to agree on how to move forward, but the conflict is
not at the technical side. For discussions around social issues,
discussing in the open is like being on public trial. It's very
stressful and very hard to find a good resolution.

On top of this, because this is the *Technical* committee, we're forced
to focus on the technical side of a problem. In various occasions this
means that there's really no solution we can offer. We're not explicit
mediators, we don't have the authority to be mediators and we're
definitely not set up in a way that leads to good mediation outcomes.

Speed
-

In many occasions in the past, the committee took too long to make a
decision.  There's many reasons for this. Perhaps we wanted to be
thorough in looking at the problem from all angles. Perhaps we wanted to
explore different alternatives to solve the issue. Perhaps we were busy
with other priorities and the discussion just moved slowly. Whatever the
case, the long time to resolution also devalues the role that the
committee has in solving issues (technical or not technical).

If the TC is going to be of value to the project it needs to act quickly
when dealing with urgent matters (for example, right before a freeze).

It's important to note that the questions brought to the TC typically
have no easy and quick solution, that's why they were brought to the TC

Re: Rethinking the role of the TC

2020-07-26 Thread Don Armstrong
These are a great start for discussion; I think every single one of them
is worth discussing, and probably deserves a BoF in its own right.

On Sat, 18 Jul 2020, Margarita Manterola wrote:
> No design work
> --
> 
> One of the constraints that the TC has to deal with is that we can't
> do any design work, it can only choose between options already
> presented to it. A consequence here is that even when we have a group
> of experienced individuals from different areas of Debian that can
> maybe come up with great ideas to solve a problem, we can't really put
> those ideas to work, as we can't do design work. Several times it has
> happened that a discussion that was interesting in nature had to be
> stopped because we were falling into the trap of doing design work.

What if the TC still didn't do design work, but instead suggested ideas
and working groups (optionally including TC members) to come up with
solutions and implementations of those solutions?

Alternatively, the TC could issue an opinion about what parameters an
ideal solution/implementation would have, and once implementation exist,
empower the winning implementation to be implemented.

> Also, related to this is the fact that the TC has the power to make
> technical decisions that developers then need to implement, without
> being involved in either the design or the implementation of those
> decisions. This can be seen by some developers as too much power with
> too little responsibility.

This is the difficult balance; at the end of the day, the TC can only
empower someone (potentially TC member(s)) to do the implementation. 

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

Some pirates achieved immortality by great deeds of cruelty or
daring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_



Re: Rethinking the role of the TC

2020-07-26 Thread Sean Whitton
Hello,

On Sun 26 Jul 2020 at 08:47AM -07, Sean Whitton wrote:

> It's late in the day but I would like to suggest including this
> paragraph in the document in some form.

Thank you for doing this in commits today.  I'd like to suggest going a
bit further, however -- how about this:

As work done inside the Debian is inherently technical, it's hard
for an issue to be *purely non-technical*, there's always something
technical behind the conflict.  But in many conflicts, the *issue
that needs solving* is of a social nature rather than a technical
nature.  In this sort of situation the TC members can readily
observe that making a decision on the technical issue will not
really help matters, but it is the only thing the TC is actually
empowered to do.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Rethinking the role of the TC

2020-07-26 Thread Sean Whitton
Hello,

On Thu 23 Jul 2020 at 07:40PM -03, David Bremner wrote:

> I think it makes sense to formalize the "I'm thinking of bringing the
> following issue to the TC" discussions that already happen, to reduce
> the amount that people need to rely on existing personal relationships.

Might be good to include this in the doc?

> I don't know whether this is a point in favour or against this proposal,
> but I don't think developers are always that great at trying other ways
> of resolving problems before bringing them to the TC. This is related to
> the issue of mediation above.

I think the idea might be to accept that people aren't very good at this
and try to help them earlier.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Rethinking the role of the TC

2020-07-26 Thread Sean Whitton
Hello Marga,

I'm sorry I didn't reply sooner.

On Sat 18 Jul 2020 at 07:50PM +02, Margarita Manterola wrote:

> This is true, TC members are expected to be able to deal with "social
> issues". But still when issues arrive at our doorstep and we come to the
> conclusion that there's no technical issue to decide upon, we are
> usually left wondering what to do about them. In other words, if the
> problem is that two members of the community are clashing in the way
> they communicate and there's no option A or option B to select from, the
> TC is ill-equipped to deal with that.
>
> [...]
>
> As work done inside the Debian is inherently technical, it's hard for an
> issue to be *purely non-technical*, there's always something technical
> behind the conflict.  But in many conflicts, the _issue that needs
> solving_ is of a social nature rather than a technical nature.

It's late in the day but I would like to suggest including this
paragraph in the document in some form.

> I think clarifying who's in charge of mediating social conflict between
> developers might help the TC, whether the TC is that body or not.
>
> If we (as in the Debian project) decide that the TC should be in charge
> of mediation between developers (as long as there's no CoC violation),
> we can establish processes to do that. Probably add a few points to the
> constitution that clarify this role, how it works, etc.  That way,
> developers can come to us and understand what they can expect from us in
> this situation.
>
> If we decide that a different body (Community Team or a new one) should
> be in charge of mediation, then we can re-direct social issues to this
> team and stop wringing our hands when there's no technical option to
> select.

I see what you mean now -- the existence of something technical
somewhere within the issue prompts the dispute to be brought to the TC,
but if the TC makes a decision on the technical side of the dispute, it
won't really help anything; the TC members can see that, but the only
thing they can do is 'solve' the technical side of the dispute, which is
not very useful.

So, you're not really talking about those very rare, purely
non-technical, non-CoC issues I mistakenly thought you had in mind.

>> With respect to the "separate responsibilities" proposal, I would like
>> to ask for more detail on how it is thought this could make the TC more
>> useful.  Right now I can't see how it would, given what I just wrote
>> about how social issues tend to come throughly tangled up with
>> technical
>> ones, except for the purely non-technical, non-CoC issues, which the TC
>> does not presently have responsibility for anyway.
>
> Well, that option is very much in the air, but I wanted to include it
> because it had been floated around in this mailing list and also during
> the talk at DC19.  The goal of that option is to basically abolish the
> TC as it is now, and in its place construct new teams that are better
> equipped to deal with each type of problem (advice & guidance, social
> conflict, technical conflict).
>
> Some developers take issue at the fact that the TC has too much power.
> So, splitting it into pieces would reduce the amount of power that each
> piece has. If we decided that this was the way to go, we'd need to work
> on the wording of exactly what each piece is in charge of.

I saw your reply to Gunnar, on salsa, that this is mostly included for
completeness.  I'm on the fence about whether that's a good idea.

If no-one in the TC wants to pursue this, then I'm concerned that
starting a discussion on it is not going to achieve anything, and lead
to fractious and overly general discussions like we saw regarding the
formation and the delegation of the Community Team.  If someone outside
the TC wanted to pursue something like this, it would of course always
be open to them start that discussion and draft the GR proposal.

On the other hand having it on the list of proposals could forestall
"what about ..."  discussion from people who aren't really in favour of
the option but are inclined towards discussing each possibility.

In the end, I'm happy to trust your judgement on whether completeness is
a good reason to keep this in, but I do think that avoiding
subdiscussions that will go nowhere but have the potential to raise the
temperature is something that teams starting discussions within Debian
should consciously try to do, given how the past year has been on the
mailing lists.

-- 
Sean Whitton


signature.asc
Description: PGP signature