Bug#741573: #741573: Menu Policy and Consensus
Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and Consensus"):
> Having such serious objections that have not been adequately considered
> means you don't have rough consensus at least in the ways I judge rough
> consensus.
Thanks for your thoughtful response and care when reading.
However, I'm afraid I think this is rather muddled thinking.
Consensus is a question about what proprtion of people hold certain
opinion. It doesn't involve a value judgement. Whereas, `adequately
considered' involves a value judgement.
> Ian> For the TC to do the
> Ian> same would mean that - when the question is controversial and
> Ian> has a strong political element - the actual decision would be
> Ian> simply be based on which side has the most effort and best
> Ian> tactics in a mailing list flamewar.
>
> I would urge you to read RFC 7282. I understand this is not the IETF
> and even the IETF has not chosen to bind itself to that document.
I see references to the IETF as a repeated theme in your writings on
these subjuects.
I'm sorry to say that the I think the IETF is a poor model for
technical decisionmaking. Indeed output from the IETF in many areas
has indeed suffered from precisely the kind of problems that one would
expect from an institution dominated by the people who have time and
willingness to argue on mailing lists. [1]
It may be difficult for the IETF to do better (because better
approaches may not scale well).
But Debian has a robust governance system and is small enough that we
can have difficult technical decisions made by a panel of highly
competent people - and that's what the TC is supposed to be.
So:
> However, I think the TC has very important roles beyond just judging
> consensus.
I think, in general, it should be no part of the TC's role to judge
consensus. (There may be exceptions.)
Privileging consensus encourages all sorts of very dysfunctional
behaviours. It encourages browbeating; wearing down of the
opposition; canvassing for supporters to come and join the fight;
asking the same question again; misrepresentation of others' views;
mailing list archeaology; arguments about who said what when; etc.
All of these are to a greater or lesser extent toxic.
> We need to decide what the policy is. We can and in my opinion should
> factor in the opinions of others in doing that.
I certainly agree that the TC should take into account the opinions of
others. But those opinions should be tested and evaluated on their
merits.
> Sam> I think the key area where we differ is that I would give preference
> Sam> other things being mostly equal to upholding the work done in
> Sam> debian-policy. As I understand it, you would vote for the option you
> Sam> thought technically best.
>
> You didn't confirm this, but it still sounds from what you've said like
> that would be a fair summary. I'm not trying to put words in your
> mouth, just confirm my understanding of your position.
> Additionally, it sounds like one of the reasons why may be that you're
> more skeptical of the technical quality of debian-policy than I am.
I'm sorry to say that I have very little confidence in the
debian-policy /process/, where it comes to controversial or difficult
questions. This is not to say that I lack confidence in the policy
/editors/; in fact, I would like the policy /editors/ to use a process
which relies /more/ on their own judgement.
The current policy process works fine for easy questions - but for
easy questions, any process will do.
In practice, where technically complex questions are successfuly
resolved, this is usually done by the relevant experts communicating
elsewhere until they reach agreement, and then perhaps, or perhaps
not, writing up their conclusions as policy changes.
It is natural that policy will act as a lightning rod for
disagreement. I think this is inevitable. But at the moment, the
policy process is ill set up for dealing with such questions.
So with the policy process as currently constituted, and because I
think consensus is such a poor guide, I think that the TC should not
be heavily influenced by the outcome of the policy process.
If the policy editors were prepared to take a more definite line
themselves, and apply their own judgement, then the situation would be
very different. But in that situation I think that for entirely
different reasons, the TC ought not to defer to the policy editors.
So either way, I think when it is deciding policy, the TC ought to be
making up its own mind on the merits.
> I think my job as a TC member is to come up with the best technical
> policy for Debian I can. I think we disagree on how to accomplish that.
Yes.
Ian.
[1] Examples of IETF-generated nonsense that I'm aware of:
* A6, DNAME, bitstring labels; now thankfully (mostly) abandonded
* Unconsidered breakage of DNS round robin load balancing
* IPv6 SLAAC vs DHCPv6
* Indeed much of the new IPv6 architecture is clearly contrary to
the intent of the IESG decision selecting IPv6
* DNSSEC, whose first iteration was undeployable
* Recent NNTP/Usenet RFCs
* Curve25519 - PinkBikeshed vs PurpleBikeshed vs ...
Reply to: