> On 16 Jan 2020, at 22:15, Kevin Smith <kevin.sm...@isode.com> wrote: > > On 16 Jan 2020, at 21:50, Daniel Gultsch <dan...@gultsch.de > <mailto:dan...@gultsch.de>> wrote: >> >> Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland <d...@cridland.net >> <mailto:d...@cridland.net>>: >>> >>> >>> >>> On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch <dan...@gultsch.de >>> <mailto:dan...@gultsch.de>> wrote: >>>> >>>> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland >>>> <d...@cridland.net <mailto:d...@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
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
