>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and >> I think the key area where we differ is that I would give >> preference other things being mostly equal to upholding the work >> done in debian-policy. As I understand it, you would vote for >> the option you thought technically best. I wouldn't do that >> because I think the social costs are important and because I >> recognize a real chance I might be technically wrong. Ian> I'm not sure precisely what social costs you are referring to. Ian> Perhaps you mean disappointment on the part of people who have Ian> spent effort to build consensus in debian-policy in order to Ian> make progress in a controversial area. But if there are Ian> serious objections, which a participant wishes to take to the Ian> TC, it seems to me that such a consensus (if it exists) has Ian> probably been achieved by wearing down the sceptics rather than Ian> by convincing them (or perhaps by the absence of the opponents Ian> to begin with). 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. It was perhaps not obvious in some of my mail, but I did: * evaluate each objection Bill raised in his mail where he reverted the change to see if I thought it was addressed at a process level. * Evaluate each of those objections as a TC member to see if I thought it was in my technical judgment a problem with the proposal. * Try to explain the objections to the rest of the TC so they could make their evaluation using their technical judgment (including pointers if they want to dig more deeply) Doing all of those are important to me. With regard to the current issue it's my opinion that we have no serious issues that have not been considered. It's my opinion that in my technical judgment I'm comfortable with the resolution to the issues that were considered. If you or anyone else wants me to look at some specific issue either from a process standpoint or to make a judgment about whether I think the resolution is reasonable, please start another thread on the bug. If I have not already voted I'll do so. I'm still in the process of doing my own technical evaluation of the proposal to see if I come up with any technical objections I consider serious enough to raise. It'll be awkward from a TC internal process standpoint if I do because the ballot is frozen at this point, but I've completed enough of my evaluation that I don't anticipate any such objections. I'll be done before I vote and will definitely be able to complete within the voting period even if Don calls for a vote now. Ian> Or perhaps you mean disappointment on the part of the policy Ian> editors. I do not. Your reasons are somewhat similar to mine. Ian> To put it another way: the policy editors have cast themselves Ian> as referees, not judges or designers. Agreed to some extent. The policy editors do have some role as consensus judges, but to a large extent they have delegated that to those seconding proposals according to their process document. In practice, I suspect they do a fair bit of consensus judging themselves. 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. However it displays some of the level of thought required in judging rough consensus. A judge of consensus is very much responsible for thinking about the technical issues and making sure they have adequately been considered. A judge of consensus is very much responsible for making sure the process does not turn into who-shouts-loudest. Someone reviewing a consensus process probably isn't in a position to fix a process where participants were driven away in frustration (silencing their objections) but should detect this sort of thing and claim the process failed to reach consensus when significant viewpoints were excluded. However, I think the TC has very important roles beyond just judging consensus. We need to decide what the policy is. We can and in my opinion should factor in the opinions of others in doing that. As a practical matter the debian-policy list does a lot of that. When debian-policy properly takes up an issueit's important to me that the TC value the work they have done. Part of that to me is that we should have a reason for deciding differently. I'd also be fine adjusting how much policy work is done by debian-policy and how much is done by the TC. There's a constitutional limit of course in that the tc cannot come up with the proposals itself (although members can be part of that). I won't drive such an effort, but if you think that we'd get better policy by changing the policy process such that when there is contraversy the proposals are tossed up to the TC to decide between, then I urge you to build support for your view and see if you can get the debian-policy process changed, or to work at the debian-project level to build support for a different role for debian-policy. Ian> Not only does [allowing the decision to be about who shouts loudest] result in bad decisions, but it rewards Ian> behaviours which are effective at generating apparent consensus Ian> on mailing lists. I'm sure it will be obvious to you that Ian> there are many behaviours which are very effective for that but Ian> which are also very harmful (indeed, which work _because_ they Ian> are harmful). In Debian we normally mitigate this problem by Ian> arranging that someone or some group is in charge of the Ian> decision and applies their own judgement. I believe that's the TC's job. I'd like to try and characterize areas where we disagree because I think it will help us understand each other and give others something to think about. In my previous mail I said: 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. Ian> Finally (and at the risk of sounding like one of those people Ian> who quote the Social Contract at every opportunity) I would Ian> like to point out that your view seems contrary to the spirit Ian> of the Constitution. Ian> The Constitution does of course say `may', so the TC isn't Ian> required to determine the content of policy. But that is just Ian> the language used when determining the powers abnd Ian> responsibilities of every constitutionally defined role. 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. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tsl8ua8w69q....@mit.edu