Re: draft alternative proposal: fix problem at the root
On Tue, Dec 09, 2014 at 01:01:12PM +0000, Ian Jackson wrote:
> Anthony Towns writes ("Re: draft alternative proposal: fix problem at the root"):
> > I think it's worth keeping those conceptually separate; if you've got an
> > arbitrator, it's important to convince them of your position. If you've
> > got a mediator, what they think is kind-of beside the point.
> Basic principles:
> * Mediators seek consensus and try to work within the existing power
> relationships. They try to determine if a compromise is possible
> and if so what that compromise is.
Maybe. I think that misses the part where a mediator tries to *improve*
interpersonal relationships -- quoting wikipedia: "Mediators use
various techniques to open, or improve, dialogue and empathy between
disputants, aiming to help the parties reach an agreement".
Allowing power relationships to have any input into the process at all
probably doesn't actually help achieve a consensus. I suspect it's
better to try to maintain the polite fiction that everyone's equal
and only the technical facts matter. If enough of us try hard enough,
it might even turn out to be true. [0]
Also, I wouldn't put the goal of mediation as merely coming up with a
"compromise", but rather as coming up with a solution that's acceptable
to everyone. Maybe that ends up being a compromise, but maybe it ends up
being a better approach that nobody had thought of until they talked
things through better.
> * Arbitrators try to produce the "right" answer (which might be
> technically, legally, socially, or whatever), sometimes according
> to a body of rules or caselaw or sometimes not.
I think imagining there's a single "right" answer to any problem brought
to the tech ctte is completely wrong. There are approaches that can be
taken, and there are consequences that result from them. Which approach
or consequences is "best" will usually legitimately depend on who you ask;
without any of them being "right" or "wrong".
Otherwise you might just as well tell everyone the right editor to
use is vi, the right desktop to use is KDE, the right init system
to use is systemd, and the right architecture to run all this on is
powerpc. That's certainly an approach you could take, but I think you'd
get better consequences by acknowledging the merits of the alternatives,
even when only one choice can be made.
(The difference for abritrators in marriage/contractual disputes, is
that (at least in theory) there was a shared principle originally --
contract, handshake agreement, statute, common or natural law -- and
it's just not clear how that principle resolves to the question at hand)
> In the "real world" it's well established that mediation tends to
> result in worse results for the weaker party than arbitration, because
> the weaker party is worse off if there is no agreement.
I'm not sure that's saying anything other than "people with property
X tend to have worse outcomes from dispute resolution process Y" and
then defining "political weakness" as "having property X" [1]. ie, it
strikes me as little more than a tautology.
FWIW, A quick search doesn't show up much on google about mediation
resulting in worse results for "weaker" parties, and a lot of what there
is is really particular to legal disputes in marriages and business
relationships, rather than relevant to technical debates as in Debian.
Anyway, there's some values for X in the above that I think are probably
acceptable; eg being unable to provide a technical explanation of your
position, or not being willing to put in the effort into implementing
your ideas yourself. Probably something along the lines of "being
uncooperative and unwilling to work towards a rough consensus" should
make you less likely to get your way via the tech ctte as well.
> This happens even if the mediation is a precursor to possible
> arbitration/litigation (that is, if it is mediation in an effort to
> avoid arbitration/litigation), because the weaker party typically has
> less confidence in the arbitration/litigation process or less ability
> to engage with it.
http://en.wikipedia.org/wiki/Best_alternative_to_a_negotiated_agreement
There's probably four relevant alternatives once arguing on a bug log
or mailing list hasn't hit consensus:
- mediated discussion leading to agreement
- tech ctte ruling
- doing a GR
- ignoring attempts at resolution and just doing whatever you want
It's perfectly rational and expected for someone who thinks they can
reliably get a much better result via a tech ctte ruling or just ignoring
everyone else to not participate effectively in a mediation.
That really only says that people will choose the negotiation mechanism
that's most biased in their favour (or equivalently least biased against
them). I don't really think there's any point worrying about that beyond
trying to limit the biases to being towards things we actually like, eg
"people who do cool stuff", "clever technical solutions", "trying for
consensus", "free software", "happy users", etc. And that's something
we should be doing anyway...
> > You could pretty easily have ctte member Alice act as mediator on a
> > dispute initially, trying to get the problem clearly expressed and to
> > make sure that everyone's concerns are at least well-understood and to
> > see if there's a mutually acceptable solution. If there isn't, and both
> > parties appear to have reasonable concerns, then Alice could recommend the
> > ctte as a whole arbitrate the dispute at that point. Maybe it would make
> > sense for Alice to refrain from participating in the arbitration step to
> > preserve the independence she needed to be involved in mediation.
>
> It is IMO a bad idea to have mediation and arbitration done by
> different people.
>
> If the arbitrators are not the same as the mediators, then any dispute
> that goes via the mediators to the arbitrators has to be explained and
> explored (at least) three times,
Anything that goes before the tech ctte needs to be explored and explained
for (at present) six people. That could mean doing it six times, but
obviously doesn't have to: you can do it in one step by preparing a good
summary that doesn't leave many unanswered questions and emailing it to
everyone at once. Doing that can be hard of course. There's a reason,
eg, that there were hundreds of mails about upstart and systemd on the
-ctte list about a year ago.
But one of the results of a "failed" mediation can simply be such
a summary of the discussions that took place, and the tradeoffs that
haven't been able to be resolved. It's possible such a summary won't be
sufficient to answer all the questions people have, but it seems likely
to me that it'll often be pretty effective.
> That's obviously undesirable because it prolongs the dispute and
> requires a great deal more of everyone's time.
I don't think that's true. [2]
Even if it was, the ctte aren't the only folks who could act as mediators.
Heck, having someone outside the ctte do the mediation job means that
if a dispute is successfully mediated, no ctte time is used. That's good
for scalability and parallelisation, for instance. [3]
[4]
(And I don't want to be snarky, but as far as prolonging disputes goes
I think if you reran Debian's last year or so through a profiler you
wouldn't find "providing technical explanations to the tech ctte" in even
the top ten hot spots blocking disputes from getting resolved quicker)
> > That still has the problem in that it still lets Bob make a heavy claim on
> > Carol's time. For example, if Carol's a release team member working on the
> > freeze and Bob wants to get a random new upstream accepted into testing,
> > then in the usual case, I don't think you'd want to force Carol to spend
> > time additional time in mediation or arguing her case or similar. Maybe
> > something like:
> I think that the TC ought to keep these kind of questions in mind when
> managing its business.
> The TC has certainly in the past dismissed complaints as ill-founded
> without needing a great deal of explanation from the maintainer.
I don't think "dismissing complaints" is a good answer here; if something
goes before the tech ctte it really should get a resolution. It's just
that if something easy/trivial comes up, that resolution should be "the
maintainer of [...] appears to be acting reasonably here, and after a
cursory review, we endorse their decision".
I'm particularly remembering bug#97671 here; I found both "We therefore
recommend that [*] The bug system administrators and/or the project
leader or some other delegates appointed by the project leader decide
on the proper use of the bug system features." and "Ie, take this damn
thing away !" quite unhelpful and frustrating.
On Tue, Dec 09, 2014 at 01:42:16PM +0000, Ian Jackson wrote:
> I think the TC should write an public document describing the process
> it will follow and the principles it will base its decisions on.
Yeah.
> - Issue is highly controversial; all further case management
> decisions will be made by full TC vote. Eg: #727708.
Putting my suggestions from [5] and [6] together, my hypothetical ideal
tech ctte would have dealt with that bug something like this:
- request to "Decide on the default init system" comes in (not from one
of the responsible maintainers)
- at the monthly IRC meeting (or maybe via email if they don't want to
wait) the ctte decides it's worth looking into, grabs a list
of reasonably neutral volunteers as candidates for doing the
investigatory step
- someone from the ctte contacts relevant maintainers to figure out
who'll be the "lead investigator"; maybe they end up picking Alice
- Alice works up a wiki page like https://wiki.debian.org/Debate/initsystem
- Alice works with the maintainers and other interested folks to collect
info about the issue, perhaps ending up with proposals "we replace
sysvinit with systemd asap", "we replace sysvinit with upstart asap",
"we make sysvinit non-essential so users can switch to upstart and
systemd easily", etc, along with how that will be achieved, and what
the impact on d-i, users, policy, the release, other packages, etc
will be.
- If there's a detail that's disputed (like systemd folks claim
upstart has unfixable design issues, but upstart folks claim its fine),
Alice looks into it, describes the facts as clearly as possible, and
notes the claims different people are making so readers can make up
their own mind.
- Alice asks the involved maintainers (so systemd, upstart, sysvinit,
openrc, d-i) and other folks who've been participating if they're happy
that the description of the options are fair, and which option they're
in favour of. Alice notes what they pick, and that they've signed
off. (If they're not happy, then refer to the "detail that's disputed"
and iterate. If everyone agrees on what what approach to take,
there's consensus; otherwise, the ctte will need to make a decision)
- Alice sends the report to the ctte. If all the maintainers involved
agreed, the ctte emails d-d-a congratulating Alice and the maintainers
for reaching consensus, and summarising what that is. If they didn't
they take it to the -ctte list to make a decision.
- The ctte look over the proposals and do their own evaluations,
referring things back to Alice and the respective maintainers if
there are additional questions or approaches that might be better.
- The ctte pick one of the proposals (needing to use the overrides power
if maintainers have said that proposal is unacceptable), and posts
the plan to d-d-a stating what's been decided and why (and summarising
what the maintainer found objectionable if they overrode anyone)
I don't think anything but the last step there needs a ctte vote,
despite the controversy.
Having ctte members be involved during the investigation is likely to be
helpful in so far as it would get questions answered earlier and possibly
get new ideas considered that might result in achieving a consensus after
all, but there's no need for them to be acting in an official capacity
(other than as a DD or perhaps maintainer of a relevant package) or to
vote on anything.
> * The TC should normally try to seek consensus (ie, take a mediating
> role). If the constitution is amended suitably, this should be
> done in private where appropriate.
So with the process above, I don't think there's any conflict with the
requirement for the ctte to act in public -- it's not the ctte that's
doing the investigation/mediation, it's an individual developer who
might not even be a ctte member. The ctte decisions happen afterwards,
and are made based on the investigation's report, which is public.
I'm tempted to argue that the investigation bit is really something
the ctte should /not/ be directly responsible for, since it's likely
to entail "detailed design work" which the ctte's forbidden from doing,
at least in theory.
> Perhaps:
> * When a complaint arrives, TC members who think the complaint looks
> like it might have some merit and be important, put themselves
> forward and say so.
Again, I'd put it as "the issue is worth investigating". It might be that
the complaint *doesn't* have merit, but it's a common mistake to make,
and it'd be good to have a clear technical explanation of why folks
shouldn't do that. Saying the "complaint has merit" kind-of prejudges
the outcome, too.
> * The TC member who is initially most favourable towards the
> complaint becomes the driver for that dispute.
That's a *terrible* idea. It makes the process completely biased, and
encourages people to go the the ctte (because going to the ctte is what
puts the bias in their favour) rather than seeking consensus.
Cheers,
aj
[0] No doubt someone's already assigning my egalitarian idealism to
whatever privilege is flavour of the day. Maybe "on the internet,
no one knows you're a dog" needs to get updated to "on the internet,
no one knows you're not a rich white male with a college education"...
[1] eg "Power has been defined by Pfeffer (cited in Kabanoff and Nesbit,
1997) as the "ability of one social actor to overcome resistance in
achieving a desired objective or result.""
-- http://www.carolynmanningconsultingservices.com.au/Power%20Imbalance%20in%20Mediation.pdf
[2] Your time usage is:
bug activity: B*2 (filer and maintainer discuss stuff for however long)
mediation: M*(m+2) (filer, maintainer and mediator discuss stuff)
arbitration: A*(c+2) (filer, maintainer and ctte discuss stuff)
general resolution: G*d (developers as a whole discuss stuff for
however long)
If you require mediation prior to arbitration, and only count times
when either mediation or arbitration resolves matters then your
scenarios are:
time cost when mediation works: M*(m+2) + B*2 time cost when
arbitration works: M*(m+2) + B*2 + A*(c+2)
Scenario 1: single mediator, ctte reviews that person's summary
and go from there if mediation fails. Mediation works X times,
Arbitration works remaining Y times.
total cost: X*(M*3 + B*2) + Y*(M*3 + B*2 + A*(c+2))
= Y*(c+2)*A + 3*(X+Y)*M + (X+Y)*2*B
Scenario 2: ctte acts as mediator, so m=c.
total cost: X*(M*(c+2) + B*2) + Y*(M*(c+2) + B*2 + A*(c+2))
= Y*(c+2)*A' + (c+2)*(X+Y)*M' + (X+Y)*2*B
Cost delta is:
(cost for scenario 1 - cost for scenario 2)
= Y*(c+2)*(A - A') + (X+Y)*(3M - (c+2)M')
Scenario 2 is better when cost delta is >0:
Y*(c+2)*(A-A') + (X+Y)*(3M - (c+2)M') > 0 Y*(c+2)*(A-A') > -(X+Y)*(3M
- (c+2)M') Y*(c+2)*(A-A') > (X+Y)*((c+2)M' - 3M)
I think c=6 is reasonable to plug in:
8Y * (A-A') > (X+Y)*(8M' - 3M)
A-A' > (X/Y + 1) * (M' - 3/8M)
X/Y > 0, so at a minimum,
A-A' > M' - 3/8M
I'd imagine mediation would generally take longer with the entire
ctte involved, which is to say M'>=M, so:
A-A' > M-3/8M = 5/8M
All of which is to say that having the whole ctte try to mediate
be the better approach would mean you'd have to be reducing the
time spent on arbitrating by more than half the time you spent
mediating (or more precisely, by a factor of (c-1)/(c+2)).
With real numbers, that'd be saying if mediation takes 30 days,
having the whole ctte involved would reduce the arbitration time by
18 days. If mediation takes 60 days, it wold reduce the arbitration
time by 37 days.
Without any data about how long it takes to mediate versus how
long it takes to arbitrate after a failed mediation, whether that's
likely is really a matter of opinion, but those numbers just don't
seem realistic to me; I wouldn't expect it to even *take* 18 days
of effort to come up with a decision once mediation was completed.
[3] Assume the ctte has c members, and a mediators pool has m members,
there are X successful mediations taking M time on average, Y things
go to arbitration taking M+A time on average.
Ctte does everything as a group, then the load on an individual
ctte member is: (X+Y)*M + Y*A
Ctte assigns one of its members as a mediator, load on an individual
ctte member is: (X+Y)*M/c + Y*A
Ctte assigns someone from a separate pool to mediate, load on:
ctte members: Y*A
mediator pool member: (X+Y)*M/m
If c=8, m=5 and X=80% of X+Y (ie 4/5 mediations succeed), those are
proportional to individual loads of:
1) 100% M + 20% A
2) 12% M + 20% A
3a) 20% A
3b) 20% M
(As per [2], it's probably reasonable to assume A(3a) > A(2) > A(1))
[4] I'm glad there's a -vote list where I can waste my time on footnotes
like the above without bothering everyone else :)
[5] https://lists.debian.org/debian-vote/2014/12/msg00050.html
[6] https://lists.debian.org/debian-vote/2014/12/msg00069.html
Reply to: