[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
function.


> >> >     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...
>

Absolutely.

Dave.
-------------- 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