What you are describing as incubating can be experimental. But in that case we need to bump XEPs to draft sooner to differentiate it properly. And in that case I don't think council should get involved in accepting XEPs as experimental at all. In any case 'experimental' should not be a mix of XEPs that can't actually be implemented (PAM, JET) and XEPs that are working good enough and are actually widely implemented (like MAM)
On Sep 1, 2017 10:55, "Florian Schmaus" <[email protected]> wrote: > I don't think that this is necessarily always true. And I always find it > strange to find unimplementable XEPs in experimental (IIRC PAM and FMUC > where or are still examples). > > That's why I've been advocating for a long time a new state before > experimental for ProtoXEPs I call 'incubating'. Just like other XEPs, IPR > for them is already handled and they get a canonical URL where a rendered > version of their latest state is available. But unlike (experimental) XEPs, > breaking changes would not require a namespace bump, they don't have a > number assigned and no registry entries are added. > > - Florian > > > > On Aug 31, 2017 16:53, "Peter Saint-Andre" <[email protected]> wrote: > >> On 8/31/17 7:49 AM, Guus der Kinderen wrote: >> > >> > >> > On 31 August 2017 at 15:37, Peter Saint-Andre <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On 8/31/17 1:59 AM, Dave Cridland wrote: >> > > On 30 August 2017 at 21:32, Daniel Gultsch <[email protected] >> <mailto:[email protected]>> wrote: >> > >> 2017-08-30 22:10 GMT+02:00 Paul Schaub <[email protected] >> <mailto:[email protected]>>: >> > >>> First things first: My intention for submitting JET to the XSF >> inbox was >> > >>> to get some comments and first feedback in order to discover >> caveats and >> > >>> pitfalls in the protocol. >> > >>> By no means I'd consider JET ready to be implemented or >> accepted :D >> > >> >> > >> OK. Fair enough. I think what people usually do at this stage is >> > >> render the XEP themselves, put it up somewhere and show it >> around to >> > >> get some feedback. That way you don't trigger council action and >> it is >> > >> way easier to make changes because you don't have to go through >> the >> > >> editor. >> > >> >> > > >> > > This is getting a bit meta, but the reason I really dislike that >> is >> > > that you're asking people to work on protocol stuff outside the >> IPR >> > > policy of the XSF. This exposes people implementing, or >> discussing, to >> > > all sorts of legal shenanigans that are somewhat mitigated by the >> > > copyright assignment in submission. >> > > >> > > If there's something preventing this, we really need to fix it. >> > >> > There is: the Council blocking publication of XEPs. Publish the >> thing, >> > get it into XSF processes, and work on the spec in the right way. >> Ship >> > and iterate! >> > >> > Which has been improved upon greatly in the past few weeks! I'm hoping >> > that we can keep that up, and improve where needed. >> >> I realize people voiced a concern with not being able to develop to the >> spec right away. That's why it's 0.1. Coders aren't stupid, they realize >> that 0.1 means it's early days. If they run into ambiguities, they'll >> provide feedback on the list. >> >> Peter >> >> >> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ >> >> > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
