[Standards] A Meta-Discussion about the Standards Process

Dave Cridland dave at cridland.net
Thu Jan 16 22:48:52 UTC 2020


On Thu, 16 Jan 2020 at 22:17, Kevin Smith <kevin.smith at isode.com> wrote:

> I think before glibly agreeing for the sake of harmony, I’d quite like to
> understand what this would entail.
>
>
I think a lot of work. But work that is well worth doing.


> The Kev/Flow plan is, as I have (I think) consistently said, the
> conceptually ‘wrong’ thing to do (although I believe that given human
> nature and where we are that it’s the pragmatic thing to do) - it is,
> though, fairly easy to understand (I think). Get rid of Inbox, make a
> formal protoXEP type that has an identifier (smith-fastening-01 or
> whatever) with no barrier to acceptance but is also not a XEP, and then
> nothing else changes - Council still have a vote on moving to XEP
> (Experimental), and human nature of not understanding why XEP-0258 is fine
> to implement in production, while XEP-0386 must not is allayed because
> XEP-0386 wouldn’t have been such, it would have been bind2-smith-1.0 or
> whatever and clearly distinct.
>

So... Would this mean that Council votes to let others implement? I assume
not, we neither prevent nor force implementation. Or is the move to
Experimental an approval of sorts now? Because if so, what is it an
approval of? Widespread implementation?

I am, I admit, picking holes in this idea - I think it could work, though I
lean toward ensuring Experimental is a "safe space" for experimentation
with XEPs which are candidates for Standardisation.


> Tidying up the unlawful East cost to make it more like the well-policed
> and gunless wild West (ok, I’m not going to pretend to be cultured or a
> student of history) is easier to see (for me) through to the end goals. We
> got here, at least in part, through people not understanding that
> Experimental means Experimental, and implementing and putting these things
> in production anyway - how would we go from here to where that’s not
> happening? There are also implications on Draft - where Draft’s barrier to
> entry would have to be lowered in order for implementable XEPs to move in
> with our friend in the wild West country, or no tidying up is really
> possible - if things that previously we thought weren’t ready to Draft
> because there were likely to be further changes that we wouldn’t want to
> inflict on (informed) production implementations become Draft, what are the
> implications for the deployments who expect Draft XEPs to be somewhat
> stable (as now).
>
>
I actually don't think there's much risk of Draft lowering in quality. We
do tend to be quite picky over Last Calls as it is (just ask poor Daniel
who is suffering through his third with XEP-0363). I do think there's a
risk of making Experimental a higher bar, and then it's harder to see what
Draft really means.


> I’m not in a position where I think the proposal of barrierless (within
> the confines of our submission rules) XEPs is a bad thing, or things moving
> to Draft is bad, or people not implimenting Experimental because it’s an
> experiment is bad - these are all things that seem self-evidently
> reasonable. I don’t see how we get to this land of hope and joy from where
> we are, and I’m concerned that there might be a degree of overoptimism in
> thinking that it’s a tractable problem to change people’s perceptions of
> the states, without having seen a fleshed-out plan for how to achieve it.
> I’d rather we moved that mountain, but I suspect it’s more realistic for us
> to move to it.
>
>
As a concrete suggestion, what about this:

1) We spend the calendar year from this Summit until the next running the
Kev Plan, and simultaneously operating the preparatory step for the Daniel
Plan of aggressively seeking candidates for advancement.
2) In time for the next Summit, we consider whether it worked, and consider
switching to the Daniel Plan, again reviewing at the Summit?


> (That said, if someone *can* come up with such a plausible plan through
> the knock-on stages etc., I think it would probably be a better idea than
> the Kev/Flow plan for the scope of XEP advancements - I still think that
> the pre-XEP stage might be a jolly good way of being able to publish things
> that just shouldn’t be XEPs, e.g. because they require licenses to
> proprietary systems or whatever, but are useful to document with less
> confusion than XEPping them in a different track).
>

I have a feeling that being able to deprecate etc these things is useful
enough to outweigh the downsides, and I think being able to move Standards
Track XEPs into the non-standard Type - and hopefully the other way - would
be useful as well.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200116/f3848a23/attachment-0001.html>


More information about the Standards mailing list