[Members] XSF @ 10
kevin at kismith.co.uk
Wed Jul 13 10:43:55 UTC 2011
On Wed, Jul 13, 2011 at 11:17 AM, Dave Cridland <dave at cridland.net> wrote:
>> For the record, the bar I use for publishing Experimental XEPs on
>> Council (and which I think there's rough agreement in the current
>> Council over) is to publish anything that isn't obviously broken or in
>> terribly bad shape (although I'm aware that there's been at least one
>> case recently where a protoXEP was blocked on different criteria).
> Right, and these are roughly the criteria I used, as well. But "obviously
> broken" and "in terribly bad shape" are in many cases fixable, and could be
> fixed during Experimental phase.
> Or, to give a rule of thumb, if the protocol's kinks were ironed out, would
> it *still* be a bad idea to have this as a XEP?
I'm not opposed to a discussion of how Council should judge
Experimental XEPs, and update of habits accordingly.
> Another rule of thumb might be that if your response is "go away and fix
> this, then we'll talk", then it's probably wrong.
I think I'm mostly agreed with this.
> You'll be perfectly aware that this suggests the original rejection of
> XEP-0301 was the wrong decision - I didn't particularly think so at the
> time, otherwise I'd have said - but in retrospect the protocol could have
> been fixed in Experimental.
301 is a /slightly/ special case, because there was, as I remember,
rough agreement within Council that the way this was done was a
terribly bad idea, not XMPPish, etc. etc. The feeling then wasn't "go
away and fix this, then we'll talk" so much as "This is wrong".
Now, subsequent list discussion changed our minds as we better
understood what was going on and that we were wrong in the first place
about it being completely unsuitable. I accept that having determined
this, the right thing may well have been to instantly accept the first
version, and wait for the second version with it hanging on the vine.
Changing process to Experimental being granted automatically, but with
Council able to kill it on the vine, would have had a different
outcome, but I *think* that, in this one case, even the changes you
suggest here would have led to 301 being being rejected initially.
On the other hand, the sensors document would have gone through, as I
believe it should have.
> *Some* vetting seems sensible - nobody wants XEP-4597 on colouring toenails,
> it's a waste of time and effort. But I think we'd benefit from a low bar.
> Something that the Council could usefully add to the vetting process would
> be to decide on what track to place the XEP on, and basically handle the
> paperworkish decisions.
A change, as previously discussed, such that Council can reject
Experimentals when they're on the vine might change things.
We might change, in that case, the Council such that instead of having
to accept something before it's published, it will review the ones
that have been recently published. I vaguely feel that this gives more
scope for "Seeing how this goes" (which would have probably been good
for 301), while still allowing 4597, colouring toenails, to have a
very short life.
> Moreover, I'd go so far as to suggest that Council members can veto on or
> before the meeting following the submission, and not have the (now) usual
> 10-day limit; I think Council members are perfectly able to form objections
> on such simple grounds quickly, and any borderline cases are safe to let
> through at this stage anyway.
It would need to be the meeting following the meeting following, in
this case (otherwise you have 30 seconds to review if it's submitted
just prior to a meeting), but I'm not opposed to changing the windows.
> Of course extensive reviews by Council and a list of things that'll have to
> be fixed are valuable outputs, but I think if a XEP needs any more than a
> quick pass and reject, it's worth giving it a number and fixing it within
> the XSF, instead of outside it.
I think I agree with this.
>> > Our Experimental XEPs don't have the same blessed status
>> > as an RFC; we should nip this one in the bud now to avoid it.
>> I'm not sure to what extent they don't, within the community, although
>> I am at least aware that *some* people will read the text at the top
>> and not implement Experimentals. So we're probably not doomed yet.
> Within the community I think is difficult to guage, but I recall that
> raising Jingle to Draft was important to various entities in order to signal
> that it was "ready".
Right. I don't think we have the IETF problem here, yet.
> It also occurs to me that - with Signed-off-by validation in place - XSF
> members could all be given commit rights to the XSF's XEP repository. I'd be
> OK with that, if a little nervous because that's not what we voted members
> on for. (Obviously the commit rights would be limited to Experimental -
> Draft/Final commit rights would be for the XEP Editor, Signed-off-by
> council at xmpp.org, I imagine).
If you're proposing that any member can edit any Experimental XEP, I
think I'm not in favour of this - at least for those XEPs with an
>> > What you'd see would then be - hopefully - a mass of low-quality XEPs
>> > published, and their supporters would then be keen to elevate them so
>> > they'd
>> > gain visibility - and it's be fairly trivial to do so.
>> Right. I think I'm in agreement with this. It seems useful (instead of
>> e.g. me keeping my own repository of protoXEPs that I know won't get
>> through to Experimental yet (e.g. missing a section on Discovering
> Right - but missing a section on discovering support seems OK to me on
> reflection, anyway. Obviously it needs fixing, but it's also obvious it can
> be fixed prior to Draft.
More information about the Members