[Members] XEP-0001 Changes

Dave Cridland dave at cridland.net
Wed Mar 5 10:33:18 UTC 2014


On 4 Mar 2014 13:39, "Kevin Smith" <kevin at kismith.co.uk> wrote:
>
> I promised feedback so ...
>
> On Wed, Feb 26, 2014 at 1:17 PM, Dave Cridland <dave at cridland.net> wrote:
> sections, "XMPP Council" has been replaced by "Approving
> > Body".
>
> This seems fine
>
> >     2) The timeouts for objecting has been removed, and replaced by...
>
> "+  <p>Within 14 days, the Chair of the Approving Body shall poll
> members of the Approving Body. "
>
> This isn't consistent with what we currently do (I think it's further
> from what we currently do than the current text is)
>

I disagree, but more on that below.

>
> "In rare cases, the Approving Body may decide that the wrong Approving
> Body may have been chosen. If the Approving Body is in doubt, the XSF
> Board shall determine the correct Approving Body.</p>"
>
> In what case is this ambiguous? The only case I can think of where the
> AB may be in doubt is where the AB is not the thing in doubt, but the
> type is.
>

That seems reasonable, yes.

> I'm concerned that the current text seems to be suggesting that the
> Board can decide that the AB for a Standards-Track XEP is in doubt and
> wants to approve it itself.
>

Two things:

a) Yes, it's more likely that a procedural XEP is wrongly marked, or some
such.

b) The Board can rewrite XEP-0001 and approve the update in order to
satisfy its evil aims. (Although the Board hasn't held a vote to be Evil,
unlike Council).

> What we currently do is essentially that we shove it on the agenda for
> the meeting following a reasonable time having passed since submission
> (so 5 minutes before the next meeting doesn't count), and then there
> is a 14day timer in which people ~vote.
>
> I think this breaks down as the current (not proposed) text plus +
> "and will then vote within the usual voting period of the AB" or such.
>

So what the current text says is that the Editor posts the ProtoXEP and a
fixed 14 day timer starts then for Council members to formally log an
objection in a meeting or on the standards list. If you take a week to put
in on the agenda, then Council has one week left to log objections; the
current text doesn't give any leeway. It also says "or at the next
meeting", and while we could toy with interpretations on what "or" and
"meeting" technically mean here in order to get the interpretation we want,
I think that's a path to ruin.

What I'm suggesting here is that the Editor posts the ProtoXEP, and you are
then mandated to put it on the agenda within 14 days, and then it's up to
you as to how long Council members have to log their objection.

It's entirely possible I've not expressed that right, in part because I'm
trying to allow you (or your successors in office) as much latitude in how
you initiate the call for objections as possible. In particular, you're
within the scope it gives you to ask for any objections on the Council
mailing list rather than in a meeting.

(It's made more complicated because of the language used, too - I can't say
"vote" because it's not a vote, but a call for any objections.)

> >     4) Changed the Approving Body for the Humorous XEPs to the Editor.
>
> The Council has (loosely) approved Humorous XEPs in the past. I am not
> happy at the thought of the Editor team being an AB, even for
> Humorous.
>

It's the "loosely" that worries me. I think the Editor team should
essentially publish whatever it feels like as far as humour goes, whilst
ensuring that it's not clashing with any technical work. Ensuring this is
probably best done by discussion with Council members, and I think the text
probably needs to say something like this. I think this is in line with
what actually happens, isn't it?

What I do not want is that we formalise our approach to humour any more
than absolutely required. An official sub-committee for humour approval
sounds awful. A discussion about whether a joke was formally approved by
the correct body equally sounds terrible.

> -  <p>Note well that no special criteria (other than acceptance by the
> XMPP Council and minimal formatting compliance) need to be met in
> order for a XEP to be granted a status of Experimental. The granting
> of Experimental status must not be construed as indicating any level
> of approval by the XSF, the XMPP Council, or the XMPP developer
> community. Implementation of Experimental XEPs is encouraged in an
> exploratory fashion (e.g., in a proof of concept) in order to gain
> experience with and iteratively improve the protocol defined therein,
> but such implementations might not be appropriate for deployment in
> production systems.</p>
> +  <p>Note well that no special criteria (other than acceptance by the
> Approving Body and minimal formatting compliance) need to be met in
> order for a XEP to be granted a status of Experimental. The granting
> of Experimental status must not be construed as indicating any level
> of approval by the XSF, the XMPP Council, or the XMPP developer
> community. Implementation of Experimental XEPs is encouraged in an
> exploratory fashion (e.g., in a proof of concept) in order to gain
> experience with and iteratively improve the protocol defined therein,
> but such implementations might not be appropriate for deployment in
> production systems.</p>
>
> I think this isn't quite right. Experimental is always done by Council
isn't it?
>

No, Procedural XEPs also go through Experimental, so it could be Board too.
See Section 8.2.

> -  <p>If an Experimental XEP is inactive (i.e., no updated versions
> are published) for a period of twelve (12) months, the XMPP Extensions
> Editor shall automatically change the status of the XEP to Deferred
> unless it is in the queue of XEPs under active consideration for
> advancement by the XMPP Council; upon submission of an updated
> version, the XMPP Extensions Editor shall change the status back to
> Experimental.</p>
> +  <p>If an Experimental XEP is inactive (i.e., no updated versions
> are published) for a period of twelve (12) months, the XMPP Extensions
> Editor shall automatically change the status of the XEP to Deferred
> unless it is in the queue of XEPs under active consideration for
> advancement by the Approving Body; upon submission of an updated
> version, the XMPP Extensions Editor shall change the status back to
> Experimental.</p>
>
> Similarly. I think changing Council to AB where the AB is exclusively
> the Council removes clarity rather than adds it.
>

Again, it's not exclusively the Council. I agree it's confusing, the
original text more or less said "where we say Council it actually might be
Board", but that itself leads to other confusions.

I could be more verbose here and say "Council (or other Approving Body)",
but that implies the Council is always an option.

> I think there are other things worth changing. I don't see why we need
> xep1 to define the path in Git of XEPs, for example.

Yes, there's no need to, though I'm not sure it matters overly. And yes,
there are almost certainly other things we can, and should, change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20140305/256c28c1/attachment.html>


More information about the Members mailing list