[Standards] Abolishing 'proposed' status for XEPs

Kevin Smith kevin.smith at isode.com
Tue Apr 24 13:57:52 UTC 2018

On 24 Apr 2018, at 14:42, Tedd Sterr <teddsterr at outlook.com> wrote:
> '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.)

I’m not entirely sold that Experimental gets lost in the pile, particularly. I think an Experimental XEP that needs work before it’s ready to go to Draft is quite similar to a XEP that has gone to Council and needs work before it’s ready to go to Draft.

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

I agree with the sentiment of Experimental + needs_changes, but we don’t actually need a new state or action flag for that - we can simply put a preface “Council Notes” into the spec in question, which is what we’ve done (more or less) for some other things in the past. The common case is going to be that the Author is shepherding through to Draft and will address Council feedback immediately. Where that doesn’t happen, we can shove a note in explaining the state, and job done, no new process (other than needing the outcome of an LC to be Draft|Rejected|Experimental, instead of just Draft|Rejected, as I suggested earlier).


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

More information about the Standards mailing list