[Council] process clarification

Matthew A. Miller linuxwolf at outer-planes.net
Thu Jul 14 14:07:16 UTC 2011


On Jul 14, 2011, at 00:59 , Kevin Smith wrote:

> On Wed, Jul 13, 2011 at 7:07 PM, Matthew A. Miller
> <linuxwolf at outer-planes.net> wrote:
>> On Jul 13, 2011, at 11:43 , Kevin Smith wrote:
>> 
>>> On Wed, Jul 13, 2011 at 6:30 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>> On 7/13/11 11:16 AM, Matthew A. Miller wrote:
>>>>> 
>>>>> On Jul 13, 2011, at 11:02 , Peter Saint-Andre wrote:
>>>>> 
>>>>>> On 7/13/11 10:33 AM, Kevin Smith wrote:
>>>>>> 
>>>>>>> 2) http://www.xmpp.org/extensions/inbox/compliance2012.html
>>>>>>> Accept as XEP?
>>>>>>> 
>>>>>>> No objections from those present, Nathan has a fortnight to
>>>>>>> object.
>>>>>>> 
>>>>>>> 3) http://www.xmpp.org/extensions/inbox/commenting.html Accept as
>>>>>>> XEP?
>>>>>>> 
>>>>>>> No objections from those present, Nathan has a fortnight to
>>>>>>> object.
>>>>>>> 
>>>>>>> 4) Issue last call on XEP-0296?
>>>>>>> 
>>>>>>> Agreement to do so.
>>>>>> 
>>>>>> After the meeting today, Kev and I had a discussion about Council
>>>>>> policies and procedures:
>>>>>> 
>>>>>> http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110713/#15:25:15
>>>>>> 
>>>>>> My feeling is that the Council could take action on acceptance of
>>>>>> XEPs and issuance of Last Calls by a simple majority of +1 and no
>>>>>> -1 votes, *without* the need to wait two weeks for absent Council
>>>>>> members to possibly object on the list. My primary rationale is
>>>>>> that Council members could always vote -1 on any advancement
>>>>>> decisions resulting from acceptance of a XEP or issuance of a Last
>>>>>> Call. My secondary rationale is that waiting two weeks just to get
>>>>>> a XEP in the system or to issue a Last Call makes our processes
>>>>>> seem slower than they need to be.
>>>>>> 
>>>>>> However, if we're going to take this approach then we need to have
>>>>>> a cut-off date for requesting these actions (as Kev noted, we don't
>>>>>> want to put something in the inbox 5 minutes before a meeting and
>>>>>> then accept it for publication).
>>>>>> 
>>>>>> Peter
>>>>>> 
>>>>> 
>>>>> This makes a sense to me.
>>>>> 
>>>>> However, does "simple majority" mean "simple majority of council
>>>>> members present at the quorum-achived meeting" or "simple majority of
>>>>> all council members"?
>>>> 
>>>> Quorum rules would still apply, so the former.
>>>> 
>>>>> It would move faster if we go with the former,
>>>>> but could mean an overall minority approval still keeps things
>>>>> moving.  I don't really see a problem with that (-:
>>>>> 
>>>>> As for the time limit, I think a 24 hour cutoff (before next meeting)
>>>>> seems reasonable, although we could probably live with 12 hours.
>>>> 
>>>> I was going to suggest 48.
>>> 
>>> Unless other Council members find themselves much less busy day to day
>>> than I do, I would imagine it would sometimes be a struggle to review
>>> in much less than 48 hours.
>>> 
>>> I do not believe the intention here is for Council to stop reviewing
>>> these proposals, so we should try not to make it impossible to do so.
>>> 
>>> /K
>> 
>> 48 hours is perfectly fine with me (-:
>> 
>> I block out time the evening before to read them, so a shorter time (and the fact our meeting is in the AM for my locale) works out for me.  As long as it's not 1 week before, and not less than 12 hours (-:
> 
> In fact, having read XEP-0001 and realised we've not been practicing
> what it preaches anyway, I suggest we go back to the published rules:
> 
> "If no member of the XMPP Council objects to publication of the
> proposal within fourteen (14) days or at the next meeting of the
> Council, the XMPP Extensions Editor shall accept it as a XEP. If
> objections are raised by the Council on the Standards list or in its
> meeting, the XEP author is encouraged to address the feedback of the
> Council and to submit a revised version of the proposal and/or confer
> with the XMPP Extensions Editor or objecting Council member(s)
> regarding how to proceed."
> 
> The maximum time to publication becomes 14 days under this, instead of
> 9 days under what's discussed above, but it means no process changes,
> and is still better that what we do now (which, it seems, we shouldn't
> be doing).
> 
> Thoughts?
> 

+1


- m&m


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/council/attachments/20110714/dc1b3a8d/attachment.bin>


More information about the Council mailing list