[Members] XSF @ 10

Kevin Smith kevin at kismith.co.uk
Wed Jul 13 09:26:16 UTC 2011

On Tue, Jul 12, 2011 at 11:54 PM, Dave Cridland <dave at cridland.net> wrote:
> What I don't think we should be doing is looking at open-source projects and
> assuming that if we squint, we can look like one. An open-source project
> produces code, and I think the requirements of an SDO are sufficiently
> different that the procedures need to also differ.

Many (I assert) open source projects are much more akin to dictator
and lieutenants and are much more inclined to positions for as long as
you're interested in holding them - I think we already have something
that's more open for the XSF.

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

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

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

> 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

> So in summary, at the moment, I think our process (and system) is more
> awkward, and less automated, than it could be. But I don't think it's
> fundamentally broken, I just think it needs a refresh. If only we knew
> people who could offer suggestions about minimizing round-trips, and some
> folk who could write code?



More information about the Members mailing list