Re: [meta] voting preparation time

On Jul 9, 2008, at 8:05 AM, Michael Schneider wrote:

> A procedural point:
>
>> -----Original Message-----
>> From: Bijan Parsia [mailto:bparsia@cs.man.ac.uk]
>> Sent: Wednesday, July 09, 2008 8:26 AM
>> To: Alan Ruttenberg
> [...]
>>> Issue 127 mentions this.
> [...]
>> Please add it to the to resolve part of the agenda.
>
> Can we please refrain from adding proposals to resolve issues to  
> the agenda
> just a few *hours* before a telco?

I asked for it a week ago.

> I have to prepare myself to votes, and have to discuss them with my
> colleagues. And I don't have the time to scan my mails all day long  
> just to
> wait for any last minute proposals to pop up.

There is this somewhat weird rule that the chairs have that things  
cannot be resolved at a telecon unless previously announced. This was  
orginally pushed as a matter of charter and process, though it is not  
(in most groups, as long as the issue was on the agenda, a resolution  
is a possible outcome of that meeting).

If you see a thing on the agenda that you care about and aren't going  
to be at that meeting, you can always request that no vote be taken.  
During a telecon, if you aren't ready to vote, you can request a  
delay. All the rule does is add an arbitrary block.

> In general, I would appreciate to have the resolve part of an  
> agenda (NOT
> the whole agenda, of course) about a week before a telco (at least  
> before
> the weekend). If it turns out that this is not possible for the  
> upcoming
> telco anymore, than just announce the proposal for the telco after.

I'm very very skeptical that this would result in more consideration.  
What's really bizarre about this instance, for example, is that my  
proposal to resolve is over a week old and it's on an issue *you  
raised* and you've not responded to my proposal on list (e.g., to  
advance the discussion). You also tend to raise a lot of issues, some  
of which, like 114, are rather speculative. I think the group should  
have the flexibility to be rather more agile in dealing with such  
issues.

Cheers,
Bijan.

Received on Wednesday, 9 July 2008 07:30:41 UTC