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 ...
