[Members] XEP-0001 Changes

Dave Cridland dave at cridland.net
Wed Mar 5 15:13:44 UTC 2014

On 5 March 2014 13:54, Kevin Smith <kevin at kismith.co.uk> wrote:

> On Wed, Mar 5, 2014 at 10:33 AM, Dave Cridland <dave at cridland.net> wrote:
> >> "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).
> The Board can rewrite XEP1, but if it proposed to do so in a way that
> meant it took technical responsibility instead of Council I hope
> people would complain. I think that's very close to what's happening
> here (albeit not maliciously) so I'm complaining. I'd suggest instead
> that the right thing to do is if the Board sees a Procedural XEP that
> should be ST, it rejects it and suggests resubmission, and vice versa
> for Council (etc. for other permutations).
Ah, I see. I suppose I'm thinking about a different problem here.

What if the Council were happy to treat a Procedural as a Council matter,
but the Board felt it was within their remit, or vice-versa? Who ultimately
decides? (We can of course get a consensus from the list; but someone needs
to be responsible for calling it).

For cases where the Council thinks it's a Board matter, it should be simple
enough to resolve, I agree.

I imagine there's a similar case without the ramifications where a document
could be either Informational or Standards Track.

A case in point for the latter is Fippo and me - we've submitted a ProtoXEP
erroneously under Historical. The Editor picked up on this and suggested
either Informational or Standards Track; Fippo picked Informational whereas
I consider it better under Standards Track. I don't actually know who
decides, there.

> >> 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.)
> I think we're agreeing on sentiment, and can tweak wording.
It might be simplest to use "Examples" to show what can actually happen,
noting which parts are mandated and which at the whim of the Council.

Ideally, after all, XEP-0001 should be both a detailed and official
description of the XEP process, and a guidebook and introduction for
newcomers. Perhaps using examples will enable us to improve the latter

> >> >     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 generally happens is that someone says (quietly) to Council that
> they're going to write a humorous XEP along a given theme, and Council
> says "Yep, that's great, XEP Editor please publish it when you receive
> it". Typically some subset of Council then see the XEP before
> publication.
> I don't like the thought of either
> 1) The Editor team being an AB (which means we then need rules around
> voting and meetings and etc. etc., and changes the way the team would
> be selected).
> 2) Automatic publication of XEPs without an AB (This is so open to
> abuse it's painful).
> I'd be much happier if we formalised some near variation on how I
> think it works at the moment, rather than trying to fix something that
> isn't particularly broken. If we want to formalise something different
> to what we currently have, I'm happy for something lightweight like
> needing approval of a single person so we don't have to get into
> voting procedures (and there are probably several people to choose
> from here, including the ED, Council Chair or potentially Board
> Chair).
Let me figure out some text around how it works now.

>> 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.
> I'm not entirely sure that any of these changes matter overly much,
> but while we're doing housekeeping...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20140305/8dbebdfa/attachment-0001.html>

More information about the Members mailing list