Steve Langasek writes ("Re: TC voting and amendment procedure"):
> In the present case neither of the non-FD options are satisfactory to me
> because as I wrote in <[EMAIL PROTECTED]>, I think
> rationale here is very important.As I responded in my mail of Sun, 23 Sep 2007 16:23:54 +0100, I think we would be better off doing what I've seen done in some courts: we vote on the decision but each write our own rationale. Otherwise we'll get bogged down in unnecessary arguments over the rationale - and what if we can agree on the decision but there is no rationale that will command a majority ? And in fact getting bogged down in unnecessary arguments over the rationale is _exactly_ what is happening here. Everyone (even AJ, it seems) agrees that glibc in sid and lenny should be changed immediately. The only thing we disagree about is the whether that's because it's a release critical bug, or because we're going to browbeat the IETF, or whatever, whether we should also mandate the change in etch, and so on. My extensive rationale, which amongst other things describes in detail the reasoning behind my conclusion that rule 9 makes no sense for IPv4, has been available for three weeks and no-one has (1) suggested concrete changes to the wording or (2) formally proposed a resolution including that rationale text or some other rationale text. The whole point of ruling on the _conclusions_, that is the _formal directions and recommendations_, without including detailed reasoning in the resolution, is precisely to allow us to proceed to make a decision despite the fact that our reasons will inevitably differ from time to time. > And a recommendation to the IETF is going to count for more if it comes with > a rationale than if it's four (or however many) people voting that the rule > should be ignored without even being able to agree on the nature of the > problem. All you need to do is vote `yes' and add a line to your message saying `I agree with this proposal for the reasons Ian sets out in his rationale'. This complaint that we should have further discussion would be more convincing if there was actually further discussion going on. I think that if you vote FD on a ballot then you are obliged to get your hands dirty fixing whatever the problem was that caused you to vote FD in the first place. In this case that means doing the detailed work of drafting alternative ballot proposals, or at least diffs to the current proposal. > At present I remain optimistic that we can reach a consensus on a document > that incorporates everyone's concerns, which is why I think further > discussion is worthwhile. However, in light of the current rate of progress > on this bug, if we can agree informally that this is in principle what we > should do I'm willing to be persuaded to postponing the rationale to a > separate vote. Our current rate of progress is approximately zero. > FWIW, this was a factor in my failure to vote, which was effectively a > time-starved "further discussion" by abstention. The constitution may allow > any one of us to call for a vote without any minimum discussion period, but > that doesn't mean I think it's a very effective way to carry out business; > especially for complex issues such as this one, I think we need to have a > good idea of what the consensus is first and call the vote only when we > think we're ready to ratify that position. I called for a vote because there had been no discussion on the matter for a week. It's true that there was little time for discussion of my detailed resolution text; since then I've been giving at least some time for draft resolutions to be considered and alternatives suggested before I call for a vote. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
