[Council] final voting reminder!

Dave Cridland dave at cridland.net
Fri Oct 24 19:24:57 CDT 2008

On Fri Oct 24 23:54:36 2008, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > On Fri Oct 24 22:51:57 2008, Peter Saint-Andre wrote:
> >> Dave Cridland: XEP-0053,
> >
> > Hmmm - I *did* register my vote, and it's even counted on the  
> tally. I'm
> > assuming this 10 days rule doesn't really mean "10 days to vote  
> yes". ;-)
> I wanted to get clarification from you about whether version 1.4rc2
> addressed your concerns.
Sure, but if there's a 10-day timer on reviewing, finding any  
possible concerns, raising them, resolving them, re-reviewing, and so  
on, then it seems there is a very real risk that timer will expire. I  
appreciate that you came back quickly with some minor edits, and as  
it happens my concerns were very minor, and had the document passed  
through without further input that wouldn't have been a bad thing  
(except for me, anyway).

> > However, the changes in the current 1.4 look fine to me. But I'd  
> like to
> > know that other folk are still okay.
> So "in future" (as you Brits say), shall we double check with  
> Council
> members for every concern that is addressed? And if so will we ever
> finish any voting, given that a completely new vote will be  
> required for
> each minor revision? And what modifications require a revote?
> Wordsmithing? Typo fixes? Changing a "may" to a "MAY"? Adding a  
> missing
> 'id' attribute? But perhaps we need a Procedural XEP defining all  
> this.
> If we can ever vote it to Active.

The purpose of the Council, as I see it - and you can correct me if  
you like - is to provide an objective and informed viewpoint of  
changes to documents.

Now the moment any concern is raised, and that member is involved  
with its resolution, the member's viewpoint isn't as objective  
anymore. So arguably, they've become the member least able to look at  
the new revision as a whole.

So yes, I'd hope the other Council members are checking the  
resolution, just to make sure it's not introduced anything unexpected.

> > And yes, I do seem to be becoming very picky about procedure,  
> don't I?
> I think you're a DoS sent from the IETF. :P

Oh, you've got clause 6 for that, no member can be an effective DoS.

> > While I'm being so picky, perhaps the right thing for the tally is
> > actually:
> >
> > a) As Date, the date when the vote was officially commenced. I'd  
> think
> > this ought to be the first meeting for which the document is  
> placed on
> > the agenda, or when the new revision were submitted.
> >
> > b) Each new revision, post-rejection, should create a new line.  
> So in
> > this case, we'd have:
> >
> > XEP-0053        -1    .    +1    +1    +1    2008/10/15
> > XEP-0053        +1    .    .    .    .    2008/10/22
> >
> > c) I suspect that we still need a 10 day timeout for those  
> "re-votes",
> > but rather than DNV they should default. This effectively means  
> you've
> > 10 days to review the changes.
> DoS.
Okay, 5 days. But if you're saying there cannot be a timer restart,  
we have a different avenue for DoS, since that veto would have been  

Would it have mattered, with this case? Doubtful. But in principle, a  
minor change to you might well be a major change to me.

Is it a good example to use to figure out the right policy? Good  
enough. I'd hate to find an example where it mattered and have to  
figure things out then.

> > I have to admit, I'd like to see vetos recorded.
> More work. Is it worth it? People can look at the list archives, the
> meeting logs, the SVN check-ins, etc., for interim discussion. We  
> log
> all that stuff for a reason.
I think it's still important data to have listed at a glance,  
somewhere, if for no other reason than it provides a guage of  
performance next year.

> >>  XEP-0206,
> >
> > Reading through BOSH I noticed other stuff that needs a bit of  
> work -
> > nothing major, just oddities.
> >
> > body MUST be empty - good.
> > server SHOULD ignore - fine.
> > server MAY send - wrong - this is not truly optional behaviour.
> >
> > "[...] SHOULD ignore it. Some implementation are known to send  
> that
> > stanza when [...]" is prefereable, to avoid the implication that  
> sending
> > the stanza is actually okay.
> >
> > Assuming you fix this, I'm +1, but as things stand that's a -1.
> Great! I love -1 votes. It means that someone is paying attention.

Ah, I only do it so I can prove I've read the stuff. ;-)

That was horribly unclear, though - I'm referring to the paragraph at  
line 220, and in particular the parentheses at the end.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Council mailing list