On 2013-03-18 15:55, Stefano Zacchiroli wrote:
How do we make an inherently archive-wide technical decision when
multiple, possibly equally valid solutions do exist?
(I think the latter part, the existence of alternatives, is
particularly
important here, as we have well-established approaches for other
cases. For instance, when one of the alternative is clearly superior,
we
usually apply some sort of "Debian's Darwinism": we wait for it to be
popular enough, we make it increasingly more mandatory in Policy or
the
Release Team pick it as release goal, we do NMUs, etc.)
1. Communication before decision-making
Problems in making decisions often come from the early stages of the
relevant discussions. For example, this can happen if the early
discussion didn't include all the stakeholders, so that some feel
excluded, or because it launches straight into nitpicking of alternative
proposals before they are fully-formed. In any discussion that starts
by people directly arguing what the conclusion should be, few of them
will back away from their publicly stated positions later on, even if
facts emerge that would have otherwise led them to a different
conclusion.
Openness
In Debian, people can't be *forced* to involve themselves in a
discussion where they're a stakeholder, but it helps to make sure it is
on the right list, that it's not buried in the middle of an unrelated
thread, and that relevant people are pinged if they don't speak of their
own accord. When someone wants to move a specific topic forward, it's
often better to explicitly call for opinions and ideas before announcing
their own proposal -- and, of course, they should try to be genuinely
open to ideas from others. Or already at this stage they can recruit
someone neutral (which could sometimes mean the DPL) to do this and
coordinate the discussion process.
Communication
Nitpicking is natural in online asynchronous discussions, but we can
still try to avoid this taking over the discussion. It can help if
people actively discourage comparing alternative proposed options with
each other at all in the initial phases of discussion, and instead
encourage people to help improve the content and form of each proposal
separately. It is better if each proposal is first challenged in
isolation, to see if it covers the necessary details, has a sufficiently
good transition plan, etc., before discussion moves to comparing the
proposed options with each other.
Once there is, for example, a wiki page describing each proposal that
e.g. includes enough detail and has a good transition plan, people can
constructively move to comparing the alternatives, hopefully keeping
questions of technical superiority separate from debating the actual
form of the proposals. But still, rather than free form discussion, it
may be better to compile in the wiki lists of arguments for and against
each proposal. And the intention should be to make the descriptions
better, rather than to win an argument -- people should try to list the
disadvantages of their own proposals, and the advantages of others'.
Transparency
When there is reasonable agreement on a set of alternative proposals,
and on arguments for and against each, there can still be significant
disagreement on how to weight the different factors and reach a final
decision. But any decision reached at this point is likely to be much
more informed than one made through a discussion where people publicly
took sides and argued loudly for their preferred option from the start.
2. Decision-making for system-wide choices
Firstly, in this kind of debate I don't think the DPL should argue for
or against specific solutions, but should seek to push discussions
forward neutrally, trying to make them progress usefully towards
positive conclusions.
For any technical decision, it's certainly not the Debian way to choose
a new tool merely because its features sound promising or because people
are arguing loudly about how some options might or might not work. Even
for something where only one choice will be implemented widely, I would
expect to see a test implementation of each proposed option before one
is chosen. In some cases this will be in packages in the main archive;
in other cases it may require a forked copy of some packages. (Better
PPA-type infrastructure, and more standardised VCS workflows, could help
here.)
Often, there will be a clear consensus winner by the time that working
implementations are ready, at least among the major technical
stakeholders. In many cases the release team can push progress on a
transition, or the d-i team can decide to switch new installations to a
new default. In these kinds of cases the DPL and others may be able to
help discussion along, but shouldn't seek to take ownership of it.
In a few cases, there will be no consensus winner, for example where
technical and non-technical preferences clash. Or we may have
successfully implemented several systems as alternatives, but have a
general view that it's not sustainable to support multiple alternatives
system-wide for a particular feature. In these kinds of cases, it may
make sense for a coordinator who's not been arguing a side in the
discussion, such as the DPL or a delegate, to take a much more active
role.
In the latter cases, the most useful action will depend on the apparent
reasons for lack of consensus and on the issue in question. It might
include pushing for deeper discussion or trying to terminate list
threads that aren't going anywhere. It might include pushing for people
to do more testing of the alternatives, or to make a quick decision. It
might include encouraging face-to-face meetings, or discouraging the
appearance that a cabal are forcing a decision on others. It might
include handing a question to the Technical Committee to resolve,
arguing for the legitimacy of a specific team making the decision, or
pushing the topic to a GR. And in a few cases it will become clear that
the options really are evenly balanced and only different by preference,
so maybe the options should include tossing a coin -- occasionally the
most harmful outcome is failing to make a decision.
Throughout the decision-making process, it's important for it to be
transparent what is happening, and for the process by which a decision
is being reached to be clear, as this will help things even if some
people disagree with the final conclusion.
--
Moray
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/35d89445e3303afe45f37d1e49fa0...@www.morayallan.com