On 1/17/20 11:05 AM, Kevin Smith wrote: > Yes, I agree with what I think you’re saying - if there is a spec published > that does what someone needs, they will implement it regardless of what the > state says at the top (or any warnings about readiness). The “Inbox+” idea > mostly just accepts that and uses the pre-XEP track to make it easy for > people to understand the state of things - because as well as the issue that > if there’s a spec people need they’ll implement it, I also believe there is > confusion because “Well, it’s been published as a XEP”;
What will make it easier or more obvious for people to understand they shall not implement a pre-XEP from inbox that we don't already have for Experimental today? > I have at least had people ask for things to be implemented (more by users > than XMPP aficionados) because they’re a XEP and therefore they are Good. I was always under the impression that users ask for features no matter if they are a XEP. "There is no XEP for it" is rather the lame excuse by developers to not implement a requested feature. If people ask you to implement a XEP (being it pre-xep, inbox, experimental, rejected or deprecated) I'd already classify them as "XMPP aficionados" to some degree. Related to that: If XSF fails to provide what the *majority of users* (even if it's a minority of developers) expect them to provide (in terms of features or speed of adoption), we'll end up with something like WHATWG: an independent working group of the top vendors that don't care if their standards get accepted by the XSF because they can basically enforce them through their market power. I don't think that's desirable. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
