[Members] XSF @ 10

Dave Cridland dave at cridland.net
Wed Jul 13 10:17:45 UTC 2011


On Wed Jul 13 10:26:16 2011, Kevin Smith wrote:
> On Tue, Jul 12, 2011 at 11:54 PM, Dave Cridland <dave at cridland.net>  
> wrote:
> > An example - it seems to be much more difficult than it should be  
> to get
> > Experimental specs published. I think it'd be worth the members  
> deciding on
> > the ground that a proposal should be rejected by the Council. One  
> case might
> > be that a deployed protocol covers this already.
> > At the moment, I think we
> > have a quality creep on our publication bar, which has the effect  
> of
> > stifling new XEPs.
> 
> 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.

Maybe the criteria should be more:

- Clashes with existing deployed protocol.
   So if someone came up with an entirely new feature negotiation  
protocol.
- Overall goal inconsistent with XMPP.
   Such as trying to replace mail with XMPP. Or the web. Or something.
- Should be persued elsewhere.
   (ie, no problem with the idea, but would be better handled by  
another SDO, or at least not here).

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?

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.

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.


> There has been discussion (with which I agree) about changing the  
> XEP
> process such that instead of there only being one point for a XEP to
> be Rejected (currently if an author asks for movement to Draftl on  
> an
> Experimental XEP, Council will either move it to Draft, or Reject it
> permanently, with no middle ground) we move to the Draft vote being
> either "Move to Draft" or "Keep at Experimental for the moment",  
> with
> an independent mechanism for Council to reject Experimental XEPs. If
> we were to do this, it lowers the perceived danger of letting
> Experimental XEPs get published and I think I'd go so far as to say
> that with this mechanism I wouldn't be opposed to publishing of
> Experimental XEPs being by request, unvetted by Council.
> 
> 
*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.

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.

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.


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


> > Another example, in the same vein - it feels, to me, that as long  
> as the
> > format is publishable, it should be possible to submit a  
> proto-XEP entirely
> > automatically. (The IETF does this with its Internet-Drafts).  
> Editing them
> > if approved should also be trivial - we have git, we have the  
> concept of XEP
> > Authors who'd require sign-off. If it then validates as a XEP,  
> new version
> > is published.
> 
> Right - if we go ahead with the proposed changes discussed above, I
> think this is an excellent idea (at the Experimental stage).
> 
> 
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).


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

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


More information about the Members mailing list