I note that my suggestion in the MUC for this was that there were three outcomes from an LC, and Council will pick which. Draft, Rejected or Experimental, and Rejected really did mean rejected.
/K > On 23 Apr 2018, at 19:11, Dave Cridland <d...@cridland.net> wrote: > > > > On 23 April 2018 at 17:59, Matthew Wild <mwi...@gmail.com > <mailto:mwi...@gmail.com>> wrote: > On 23 April 2018 at 16:46, Dave Cridland <d...@cridland.net > <mailto:d...@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 > <https://mail.jabber.org/mailman/listinfo/standards> > Unsubscribe: standards-unsubscr...@xmpp.org > <mailto:standards-unsubscr...@xmpp.org> > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > <https://mail.jabber.org/mailman/listinfo/standards> > Unsubscribe: standards-unsubscr...@xmpp.org > <mailto:standards-unsubscr...@xmpp.org> > _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
