[Standards] A Meta-Discussion about the Standards Process

Kevin Smith kevin.smith at isode.com
Fri Jan 17 10:05:50 UTC 2020

On 17 Jan 2020, at 09:54, Marvin W <xmpp at larma.de> wrote:
> On 1/17/20 10:29 AM, Kevin Smith wrote:
>>> I need a feature X *now* and all I see is
>>> an experimental XEP I have two choices; Implement that Experimental
>>> XEP or create something myself.
>> I don’t think making the barrier to entry to Experimental lower (or Draft) will change that fact, so if this assessment of the cause is right, we’ll still be in the same position
> I think the important part when having a higher bar on Experimental is
> that it won't solve this issue either. The higher bar already means that
> people start implementing things that are in inbox. This happened for
> example with the Reactions XEP and if I wanted to implement Reactions
> today, I'd certainly use what is in the inbox now. Also aesgcm links are
> widely used while stuck in inbox.
> To phrase it differently:
> Previous way:
> Deemed ready by XSF: Draft+
> People implement: Experimental+
> Current way:
> Deemed ready by XSF: Draft+
> OKish by XSF: Experimental
> People implement: Inbox+
> I don't see any improvement. It will always be the case that some people
> implement the protocols as soon as they are publicly accessible and if
> it turns out those protocols work well enough, others will follow.
> Having a higher bar before the XEP is adopted by XSF will just result in
> less being adopted by XSF and not less (pre-)experimental things being
> implemented.

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”; 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 think it might also be easier for us to stick to that process than the current one, which experience suggests is easy to let slip.


More information about the Standards mailing list