[Standards] Abolishing 'proposed' status for XEPs

Dave Cridland dave at cridland.net
Mon Apr 23 18:11:16 UTC 2018


On 23 April 2018 at 17:59, Matthew Wild <mwild1 at gmail.com> wrote:

> On 23 April 2018 at 16:46, Dave Cridland <dave at cridland.net> wrote:
> > -1 to removing Proposed. We only know there's a problem because a bunch
> of
> > XEPs are sitting in Proposed; removing Proposed wouldn't remove the
> problem,
> > just the fact we can see it. I'd really like a similar state during the
> CFE,
> > since that's quite hard to manage.
>
> I believe the problem is completely artificial, and only exists within
> the framework that we constructed.
>
> There is a different between "this XEP is not ready for Draft" and
> "this XEP should be rejected". The 'Rejected' state was included in
> the process as an intentional dead-end, not a holding place for XEPs
> which may come back to life (Deferred is more appropriate for that).
>
> 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.


> > My preferred change would be to update XEP-0001 such that anyone can
> fish a
> > XEP from Rejected back to Experimental (without a vote) by an update,
> much
> > as Deferred XEPs can be recovered.
>
> 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.


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


>
> Regards,
> Matthew
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180423/9298cd2b/attachment.html>


More information about the Standards mailing list