[Standards] Abolishing 'proposed' status for XEPs

Matthew Wild mwild1 at gmail.com
Tue Apr 24 09:29:37 UTC 2018

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.

>> 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

>> > 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.


>> > 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.

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

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.

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.


More information about the Standards mailing list