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 particularlyimportant here, as we have well-established approaches for othercases. For instance, when one of the alternative is clearly superior, weusually apply some sort of "Debian's Darwinism": we wait for it to bepopular enough, we make it increasingly more mandatory in Policy or theRelease Team pick it as release goal, we do NMUs, etc.)
1. Communication before decision-makingProblems 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.
OpennessIn 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.
CommunicationNitpicking 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'.
TransparencyWhen 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 choicesFirstly, 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