Re: [Standards] Abolishing 'proposed' status for XEPs

[Kevin Smith]

On 24 Apr 2018, at 16:23, Tedd Sterr  wrote:
> 
> > Another note: the council may generally want to advance a XEP but vote
> > not to issue Last Call because of outstanding issues. We don't have a
> > special status for that. I can think of a number of XEPs in that
> > category.
> 
> outstanding_issues 
> 
> (Though this doesn't seem entirely different from needs_changes to me.)

I wonder if keeping track of this within the XEP would encourage earlier 
Council review, instead of waiting for LC.

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Tedd Sterr]

> Another note: the council may generally want to advance a XEP but vote
> not to issue Last Call because of outstanding issues. We don't have a
> special status for that. I can think of a number of XEPs in that
> category.


outstanding_issues 


(Though this doesn't seem entirely different from needs_changes to me.)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Kevin Smith]

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

Yes.

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

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Dave Cridland]

On 24 April 2018 at 10:29, Matthew Wild  wrote:

> On 23 April 2018 at 19:11, Dave Cridland  wrote:
> > On 23 April 2018 at 17:59, Matthew Wild  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.
>
>
In that case it's an argument for doing nothing, other than ensuring that
XEPs leave Proposed after any Council vote.


> >> 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
> protocols.
>
>
But more or less anything is an acceptable Experimental XEP. You have to
work hard to get a XEP accepted into Experimental, and then made
permanently, irrevocably, unacceptable. And even then, surely it can be
modified, at least in principle?


> >> > 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.
>
> ???
>
>
Given there is no circumstance where a XEP once acceptable to Council as
Experimental cannot be - in principle - returned to that state, you are
arguing that, since Rejected is a terminal state, it can never be used.


> >> > 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.
>
>
We've not rejected anything since 2003, as far as I can tell, and we've
only ever done so five times.

I think that's because it's a terminal state, and it's foolish to think
Council can declare some XEP so irretrievably broken it can never be
rehabilitated.

A state we haven't used in 15 years probably doesn't have a place in our
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
>
>
You're simplifying; it also means in practise that it is in Last Call.


> 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.
>
>
I entirely agree that things linger in Proposed for longer than they
should. I entirely agree that this is, in part, because XEP-0001 proscribes
moving XEPs back to Experimental.

But we only know that XEPs are in this limbo state because we have a
defined state to limbo them in; I think having such a state is useful
(though I agree Proposed should not be it).

Take XEP-0363, for example. This entered Proposed in late January, and was
Last Called. On the 7th Feb, Georg used his veto to prevent advancement,
citing the missing Security Considerations around using HTTP Upload to
bypass corporate network security. (I later also issued a veto 

Re: [Standards] Abolishing 'proposed' status for XEPs

[Matthew Wild]

On 23 April 2018 at 19:11, Dave Cridland  wrote:
> On 23 April 2018 at 17:59, Matthew Wild  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
protocols.

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

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Kevin Smith]

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  wrote:
> 
> 
> 
> On 23 April 2018 at 17:59, Matthew Wild  > wrote:
> On 23 April 2018 at 16:46, Dave Cridland  > 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-unsubscr...@xmpp.org 
> 
> ___
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Dave Cridland]

On 23 April 2018 at 17:59, Matthew Wild  wrote:

> On 23 April 2018 at 16:46, Dave Cridland  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-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Matthew Wild]

On 23 April 2018 at 16:46, Dave Cridland  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).

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

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

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

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Dave Cridland]

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

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.

Note that a XEP can't go from Rejected -> Experimental -> Proposed -> Draft
without having the factors leading to its rejection corrected or rendered
irrelevant by time.

Rejected therefore becomes a state indicating that the XEP cannot advance
in its current form, instead of a terminal state.

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.

Dave.


On 23 April 2018 at 15:09, Matthew Wild  wrote:

> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
>
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
>
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
>
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).
>
> Thoughts welcome.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Kevin Smith]

On 23 Apr 2018, at 15:09, Matthew Wild  wrote:
> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
> 
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
> 
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
> 
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).
> 
> Thoughts welcome.

I agree with doing something. I don’t have particularly strong feelings on 
which of these two somethings is more appropriate.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Abolishing 'proposed' status for XEPs

[Peter Saint-Andre]

On 4/23/18 8:09 AM, Matthew Wild wrote:
> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
> 
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
> 
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
> 
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).

+1 to removing Proposed.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___