[Standards] Abolishing 'proposed' status for XEPs

Tedd Sterr teddsterr at outlook.com
Tue Apr 24 13:42:42 UTC 2018


'Proposed' represents an intermediate state of "Experimental + awaiting vote to advance to Draft." The outcome of such vote, may either be: success (advance to draft), failure (rejected), or changes needed (..limbo).

I think that rejected represents an irredeemable failure, which is why it's so rare, but moving a not-quite-ready-for-draft XEP to rejected feels wrong; while moving back to experimental tends to get them lost in the pile - hence why there are so many collecting in Deferred state. (I actually think there should be a fully expired blackhole state after deferred-for-several-years, but that's another argument for another day.)

So, all of this seems to suggest a requirement for a new "changes needed before advancing to draft" state - that way, the XEP is not rejected, but also doesn't get lost in experiments, nor festers in 'proposed' limbo. It also makes explicit what's required next.

"We really don't want to introduce a dozen more intermediate states to faff around with!" - I hear you cry. And I agree, it is too many states. I think the better alternative would be a set of action-flags to indicate such things and the states remain the same.

So, if we have the following action-flags: needs_vote, needs_changes; then we can remove proposed and replace it with "Experimental + needs_vote", and the result of an unsuccessful-but-not-rejected vote would become "Experimental + needs_changes". This has the added benefit of providing an intermediate state for XEPs moving from draft to final "Draft + needs_vote" and then potentially "Draft + needs_changes". Searching for where votes or changes are needed becomes a trivial filter, regardless of current state.

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


More information about the Standards mailing list