[Standards] A Meta-Discussion about the Standards Process

Kevin Smith kevin.smith at isode.com
Thu Jan 16 22:17:03 UTC 2020



> On 16 Jan 2020, at 22:15, Kevin Smith <kevin.smith at isode.com> wrote:
> 
> On 16 Jan 2020, at 21:50, Daniel Gultsch <daniel at gultsch.de <mailto:daniel at gultsch.de>> wrote:
>> 
>> Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland <dave at cridland.net <mailto:dave at cridland.net>>:
>>> 
>>> 
>>> 
>>> On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch <daniel at gultsch.de <mailto:daniel at gultsch.de>> wrote:
>>>> 
>>>> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland <dave at cridland.net <mailto:dave at cridland.net>>:
>>>> 
>>>>> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well anything. If this sounds radical to you, it might help if I described it as simply reimposing the de-jure standards process as described in XEP-0001. I can certainly see the attraction, but I also think it ignores the status quo and the problems alluded to above. Most recently suggested by Daniel Gultsch.
>>>> 
>>>> If the status quo does not reflect the process described in XEP-0001
>>>> then maybe the status isn’t quo and we should strive to fix that
>>>> instead of changing the process.
>>>> 
>>>> If we manage to clean up 'experimental' by advancing what deserves to
>>>> be advanced and documenting issues in widely-deployed but not ready to
>>>> be advanced XEPs I think 'experimental' can become a home for
>>>> controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
>>> 
>>> 
>>> I will very heavily resist us placing anything knowingly encumbered onto the Standards Track in any form.
>>> 
>>>> 
>>>> After all that state contains a big fat warning saying: "Publication
>>>> as an XMPP Extension Protocol does not imply approval of this proposal
>>>> by the XMPP Standards Foundation". Just because we have seen that
>>>> warning so many times that we have learned to ignore it doesn’t mean
>>>> it's there.
>>>> 
>>>> Note that what I’m suggesting here is has an order of operations:
>>>> Clean up experimental first and then, and only if successful, start
>>>> making it the 'everything goes' state[3].
>>>> 
>>> 
>>> I don't understand this - if we're making Experimental the wild west (and, Peter, I am speaking metaphorically here), then why "clean it up"? I might find myself in agreement, mind, I simply don't understand what you mean here.
>> 
>> I think we are currently in a situation where developers implement and
>> deploy experimental XEPs which made us more and more careful of what
>> we accept as experimental. When I say clean up I mean advancing
>> certain XEPs to draft to get into a situation where developers can
>> take the "Do not implement this XEP in production" warning serious
>> again because there are enough 'draft' and 'stable' XEPs to choose
>> from.
> 
> I think before glibly agreeing for the sake of harmony, I’d quite like to understand what this would entail. 
> 
> 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.
> 
> 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

*harder*. Is *harder* for me to see through.

> 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’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.
> 
> (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).
> 
> /K

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


More information about the Standards mailing list