Re: TC voting and amendment procedure
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 <20070923084028.GE22117@dario.dodds.net>, 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.
Reply to: