[Standards] Abolishing 'proposed' status for XEPs

Dave Cridland dave at cridland.net
Tue Apr 24 10:31:50 UTC 2018


On 24 April 2018 at 10:29, Matthew Wild <mwild1 at gmail.com> wrote:

> On 23 April 2018 at 19:11, Dave Cridland <dave at cridland.net> wrote:
> > On 23 April 2018 at 17:59, Matthew Wild <mwild1 at gmail.com> wrote:
> >> I think the typical negative vote from Council members is a statement
> >> of opinion that the XEP is not ready to be advanced. This is different
> >> to actively rejecting the XEP, which is something that happens in rare
> >> circumstances (but has happened, for one reason or another).
> >>
> > This is an argument for getting rid of Rejected, not getting rid of
> > Proposed.
>
> Actually it's just an argument in favour of keeping Rejected for
> things that have, you know, been rejected.
>
>
In that case it's an argument for doing nothing, other than ensuring that
XEPs leave Proposed after any Council vote.


> >> So the only difference between Rejected and Deferred would become
> >> "this XEP had the misfortune of having been considered for Draft and
> >> receiving some negative feedback".
> >>
> >
> > This is an argument for getting rid of Rejected, not getting rid of
> > Proposed.
>
> No, it's an argument for not abusing Rejected for things that are
> still acceptable Experimental protocols but not acceptable Draft
> protocols.
>
>
But more or less anything is an acceptable Experimental XEP. You have to
work hard to get a XEP accepted into Experimental, and then made
permanently, irrevocably, unacceptable. And even then, surely it can be
modified, at least in principle?


> >> > Rejected therefore becomes a state indicating that the XEP cannot
> >> > advance in
> >> > its current form, instead of a terminal state.
> >>
> >> I think this would only be valuable if we do a better job of recording
> >> (perhaps in the XEP), the reason why it was rejected.
> >>
> >
> > This is an argument for getting rid of Rejected, not getting rid of
> > Proposed.
>
> ???
>
>
Given there is no circumstance where a XEP once acceptable to Council as
Experimental cannot be - in principle - returned to that state, you are
arguing that, since Rejected is a terminal state, it can never be used.


> >> > There is, however, a gotcha here. A Council vote on Approval (ie,
> >> > advance to
> >> > Draft) can have three outcomes. The vote can pass, in which case the
> XEP
> >> > moves to Draft. Someone can veto, in which case it moves to Rejected
> >> > (until,
> >> > in this new world, someone addresses the reasons behind the
> rejection).
> >> > But
> >> > it can also simply not gain sufficient votes - in which case there is
> >> > nothing, really, to address, per-se, but nevertheless it moves to
> >> > Rejected.
> >> >
> >> > But perhaps that's OK.
> >>
> >> In the current process, it's not, because we're not able to pull it
> >> back to Experimental. Which is why so many XEPs are lingering in
> >> Proposed.
> >
> > This is an argument for getting rid of Rejected, not getting rid of
> > Proposed.
>
> Getting rid of Rejected was not something I suggested even once. On
> the contrary, I indicated that Rejected has a place in our process for
> XEPs that have been voted by Council to have no future in our
> standards process.
>
>
We've not rejected anything since 2003, as far as I can tell, and we've
only ever done so five times.

I think that's because it's a terminal state, and it's foolish to think
Council can declare some XEP so irretrievably broken it can never be
rehabilitated.

A state we haven't used in 15 years probably doesn't have a place in our
process.


> The discussion is about the removal of Proposed. In my opening email I
> did ask if someone could provide a justification for Proposed, and why
> XEPs should be able to linger there.
>
> The current documented meaning of Proposed is:
>
>   - Council agreed that the XEP was worthy of considering advancement
>
>   - Council has not yet voted to advance to Draft or to move it to Rejected
>
>
You're simplifying; it also means in practise that it is in Last Call.


> We are clearly not following this. A random example, advancing
> XEP-0363 was -1'd during a council meeting. It should be in Rejected
> right now, and any new update would need a new XEP number. However
> that's obviously in nobody's best interests, so it's lingering in
> Proposed, even though at heart it's just an Experimental XEP that
> attempted to become a Draft.
>
>
I entirely agree that things linger in Proposed for longer than they
should. I entirely agree that this is, in part, because XEP-0001 proscribes
moving XEPs back to Experimental.

But we only know that XEPs are in this limbo state because we have a
defined state to limbo them in; I think having such a state is useful
(though I agree Proposed should not be it).

Take XEP-0363, for example. This entered Proposed in late January, and was
Last Called. On the 7th Feb, Georg used his veto to prevent advancement,
citing the missing Security Considerations around using HTTP Upload to
bypass corporate network security. (I later also issued a veto citing more
general concerns with the Security Considerations).

According to our process, the XEP should now move to Rejected, except since
it cannot ever return from that, nobody wants to do that.

So it stays in Proposed, and we hand-wave a lot about how it then might
advance.

This has the advantage that a quick flick through the XEPs shows up every
XEP that's stuck in this way. If we simply bounced things back to
Experimental, we'd have no real idea about the 6 XEPs that are stuck in
this situation. Every single XEP there is a process failure.

But we need to know about process failures, not hide them. Removing
Proposed is the moral equivalent of brushing the dust under the rug. The
problem will still remain; we just won't be able to see it anymore.

If instead Council were free to move things to Rejected, and from there
they could be easily moved to Experimental (and, from there, directly back
to Proposed, with luck), then we also wouldn't have things stuck in
Proposed unless Council (or Board) had simply forgotten to vote. In some
cases, Council might opt to move it directly to Draft from Rejected after a
change is applied.

Without going through each of the 6 XEPs in this state, I cannot tell you
why they're stuck in Proposed. Did I forget to put them on an agenda for a
vote? Did we vote, reject, but ignore our process because that bit is
broken? Did we forget to even issue the Last Call? Or maybe the Last Call
is still in progress.

On the other hand, the one thing I can conclusively say is that we have 6
XEPs which are stuck and need action. If they'd simply bounced back to
Experimental, I wouldn't know. If they'd been moved to Rejected, I would
know both that they were stuck, and also roughly why - that they weren't
suitable for advancement but nobody was fixing the issues.

XEPs getting stuck in Proposed is a symptom, not the underlying problem.


> Also worth noting is that XEPs in Proposed don't have a way to get to
> Deferred, either. They can stay there indefinitely with no updates.
>
> I'm just trying to simplify our process, make it less confusing for
> people to understand, and not have XEPs get "stuck" in an ambiguous
> state for eternity. The editors have enough to deal with already.
>

For what it's worth, the lack of such a state in the Draft => Final stage
(CFE etc) means it's much harder work for me to track down what needs
voting on there.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180424/bc431fa7/attachment-0001.html>


More information about the Standards mailing list