[Members] [Standards] Renaming XEP status 'Draft' to 'Stable'

Kevin Smith kevin.smith at isode.com
Mon Nov 6 10:37:02 UTC 2017

> On 6 Nov 2017, at 10:34, Dave Cridland <dave at cridland.net> wrote:
> On 6 November 2017 at 10:26, Kevin Smith <kevin.smith at isode.com> wrote:
>> On 6 Nov 2017, at 10:23, Dave Cridland <dave at cridland.net> wrote:
>>> On 6 November 2017 at 09:59, Kevin Smith <kevin.smith at isode.com> wrote:
>>>> On 1 Nov 2017, at 12:35, Matthew Wild <mwild1 at gmail.com> wrote:
>>>>> Guus der Kinderen recently sparked a discussion about revising our XEP
>>>>> statuses for better clarity about their intention (thread at
>>>>> https://mail.jabber.org/pipermail/standards/2017-September/033441.html
>>>>> ).
>>>>> Although the thread contains a number of points made by various
>>>>> people, te proposal emerged around renaming the "Draft" status to
>>>>> "Stable", with the reasoning that it better represents the way the
>>>>> status is understood and used.
>>>>> The XSF Board is required to approve changes, such as this, to the XEP
>>>>> standards process documented in XEP-0001. The Board is happy to
>>>>> consider this change if a positive response is received from the
>>>>> community of both XEP authors and members of the community who use and
>>>>> refer to XEPs.
>>>> I think, given this is a (very) disruptive change (there is a lot of material out there referring to the existing statuses), that we should be looking for a higher bar than just a ‘positive response’. I suggest that instead we should be convinced that there is a definite advantage to this to make it worth the disruption. At the moment it feels to me like maybe Stable would be a better description than Draft, if we were starting from scratch, but that this big a disruption this far into the life of our standards isn’t warranted unless someone can come up with a convincing argument. I don’t think “Draft dissuades people from implementing it if they don’t read what Draft means” is /that/ convincing - if people aren’t reading a sentence describing what Draft means, they’re probably not reading very much of the spec either.
>>> Despite having actually made the particular suggestion, I'm not
>>> actually that invested in it, but I don't think your last argument
>>> particularly holds - people have a solid understanding of what a
>>> "Draft" is, and what it means. As I noted before, anyone with an
>>> expectation of what it means in standards terms is likely to have that
>>> from the IETF term which no longer exists.
>>> So the idea that some people might not read a sentence in XEP-0001
>>> should also suggest they don't read the Draft specification itself
>>> seems wrong - I don't think there's any reason why one should follow
>>> the other. XEP-0001 really ought to be needed to be read only by those
>>> of us actually working on standards, and not every implementer.
>> I was thinking of the line at the top of each spec that explains what the state means, rather than xep1. I wouldn’t argue that implementors need to be intimately familiar with xep1.
> Having myself forgotten about that line, I suspect this is largely
> boilerplate that slides past people.
>>> I think "Draft dissuades people from implementing" is perfectly sound
>>> reasoning, though it'd be lovely to get this idea from more than just
>>> anecdotal evidence.
>> Possibly. Although Draft is *supposed* to give a warning that it’s not Final yet.
>> If the argument is that we want everyone to treat Draft and Final in the same way, a more significant overhaul that does away with Final and Draft, and replaces both with Stable might be more useful. Obviously we’d need to make some changes to criteria for newStable compared to either Final or Draft, but it’s probably simplifying the process (which is largely two-state anyway, in reality, and it sounds like people want to make it more so).
> I'd be worried that making Draft into Final might also risk making
> Experimental into Draft, which would be a very bad thing.

I was thinking more of binning Final than making Draft into Final. So there wouldn’t be a state where any changes are impossible, but just a state where we try not to make them.

> Perhaps deciding what the difference really is, and whether we need
> it, would be useful.

A clear statement of the real problems we’re trying to solve and the effect they’re having seems sensible, yes.


More information about the Members mailing list