[Members] XEP-0001 Changes

Kevin Smith kevin at kismith.co.uk
Wed Mar 5 13:54:34 UTC 2014


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

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

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

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

What we are doing at the moment doesn't seem to fall at any of these hurdles.

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

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

Ignore both points, I was wrong.

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

/K


More information about the Members mailing list