Re: [Standards] Tidying Deferred

[Evgeny]

On Fri, Jan 18, 2019 at 12:19 PM, Dave Cridland  
wrote:
is that those same people will expect to be able to have their 
specifications rubber-stamped through the process.


I fail to see how this is even possible within the XSF process.
If the spec is bad it will get -1 from the Council.
But I, however, agree that we should not require an implementation
during an experimental stage.

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

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Thu, 17 Jan 2019 at 17:41, Ненахов Андрей 
wrote:

> чт, 17 янв. 2019 г. в 15:38, Ralph Meijer :
> > This is explicitly not how our standards process has been set up. The
> > idea here is that having a published document as a starting point makes
> > it more likely that people are not entrenched in particular early design
> > choices, and discussion on those happen within the greater community.
>
> Yes, so far this process has led XMPP to a great success, with jabber
> being used as a primary communication protocol by a significant
> portion of internet users.
>

XMPP has always struggled with being a primary communications method for a
significant portion of internet users. On the other hand, it is widely used
within a broad selection of niche areas (frustratingly, to me, many of
these are not federated).

However, our greatest successes haven't correlated with standards which
were brought to the XSF having already been implemented - they have
occurred where multiple implementors collaborate, openly, from an early
stage.

Examples of the former include Jingle, where we still struggle with any
kind of interoperability.
Example of the latter include MUC.

I think early implementation is very important - which is why I argued we
should remove barriers to it such as the old "tmp" namespace strategy, for
example, and I personally weight implementation very highly in advancement,
even when it's not strictly required. But the risk of imposing a rule that
says people must implement first, and standardise later, is that those same
people will expect to be able to have their specifications rubber-stamped
through the process.

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

Re: [Standards] Tidying Deferred

[Evgeny]

On Thu, Jan 17, 2019 at 8:41 PM, Ненахов Андрей 
 wrote:

Yes, so far this process has led XMPP to a great success, with jabber
being used as a primary communication protocol by a significant
portion of internet users.


You will be now told that this is irrelevant and basically
everything XSF does is irrelevant to XMPP success :)

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

Re: [Standards] Tidying Deferred

[Jonas Schäfer]

On Donnerstag, 17. Januar 2019 15:51:29 CET Florian Schmaus wrote:
> > - What even is the point of Deferred if authors can opt-out of it? Or
> > rather, what gain does Experimental bring an author aside from "it
> > doesn’t look as bad" (which I think it rightfully does)?
> 
> It signals that there is someone which cares enough that it stays in
> Experimental. It appears to be very similar to what we do with the list
> of clients/servers/libraries and hence it has a certain appeal to me.

To be a useful indicator, it requires that it is signalled periodically. I 
(with my Editor hat) do not like the bookkeeping which comes with that, to be 
honest.

kind regards,
Jonas


signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Ненахов Андрей]

чт, 17 янв. 2019 г. в 15:38, Ralph Meijer :
> This is explicitly not how our standards process has been set up. The
> idea here is that having a published document as a starting point makes
> it more likely that people are not entrenched in particular early design
> choices, and discussion on those happen within the greater community.

Yes, so far this process has led XMPP to a great success, with jabber
being used as a primary communication protocol by a significant
portion of internet users.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Peter Saint-Andre]

On 1/17/19 3:43 AM, Ralph Meijer wrote:
> On 17/01/2019 11.25, Evgeny wrote:
>> On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland  wrote:
>>> we do not require it until Final - not even Draft has an absolute
>>> requirement.
>>
>> I thought transitioning to Draft requires Call For Implementors,
>> but whatever. Again this raises a question about how sane all
>> those XEP statuses nowadays. I know this is copied from IETF
>> workflow, but they have the same problems: a large number of RFCs
>> without implementations or with abandoned partial implementations.
>>
>> But since the XSF standards development is severely understaffed
>> I think raising these questions makes even less sense (actually
>> this is true for almost any XSF workflow nowadays because of this).
> 
> I don't see large numbers of specifications being abandoned as a
> problem. It is a trove of thought experiments, some with code to go with
> it, that might be of use later. Leaving them as Deferred doesn't costs
> us anything.

+1!

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

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 14.29, Georg Lukas wrote:

[..]

I agree with the idea of crowd-sourcing the review of Deferred XEPs, and
to allow anyone to propose them for LC, with the LC resulting in either
of:

- Rejected or Obsolete (we have consensus that this is a dead end)
- Experimental with new author (if somebody volunteers to move it forward)
- stay in Deferred, because the exact status can not be determined.


Just to make it clear, (the first part of) the current process is as 
follows:



Before an Experimental XEP may be proposed to the Approving Body for 
advancement to Draft (Standards Track XEPs) or Active (Historical, 
Informational, and Procedural XEPs), the Approving Body must agree that the XEP 
is ready to be considered for advancement. Once the Approving Body so agrees, 
it shall instruct the XMPP Extensions Editor to (1) change the status of the 
XEP from Experimental to Proposed and (2) issue a Last Call for open discussion 
on the Standards list. [..]


This means that if the Approving Body does *not* agree the XEP is ready 
to be considered for advancement, it stays Experimental, without a Last 
Call. I think the same should hold for proposing advancement of Deferred 
XEPs to Draft.


Of course a negative decision here will come with reasons. If there is 
such interest, (new) authors can then pick up the XEP and have it move 
from Deferred to Experimental by editing the XEP to address those 
reasons for declining consideration.


The rest of the process after issuing Last Call then is the same as before.

XEP-0001 mentions that the XEP Author is expected to make changes during 
this process, but I think that if it is determined that the original 
author has abandoned it, the Approving Body could consider the person(s) 
that proposed advancement to take on that role.


I just issued a PR [1] with changes to XEP-0001 to address the above.

[1] https://github.com/xsf/xeps/pull/744

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

Re: [Standards] Tidying Deferred

[Philipp Hörist]

Hi,

I think moving a XEP out of Deferred just because someone asks the editor
to do it (because someone cares but not the Author) seems like just adding
more work load on the Editor for the only gain that some people like the
word "Experimental" more than "Deferred"

This feels like not working on the actual problem, and just using a short
term bandaid, because after 12 Months the same process has to be done
again. Seems pointless.

The actual problem in my opinion is, that authors do not sponsor the XEP
till the end of the process.

The state deffered tells us exactly that, an idea of a standard but there
is no one that cares enough to sponsor the XEP.
And only because a client developer spends X hours to implement that XEP
does not mean it has to be kept from now on in experimental till the end of
time.

Actually i think implementations should have zero effect on any of these
decisions.

Of course it might be useful to revisit deferred XEPs.

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

Re: [Standards] Tidying Deferred

[Florian Schmaus]

On 17.01.19 15:35, Jonas Schäfer wrote:
> Also replying to Goffi implicitly.
> 
> On Donnerstag, 17. Januar 2019 14:29:41 CET Georg Lukas wrote:
>> * Tedd Sterr  [2019-01-16 21:50]:
>>> My own preference would be for Deferred to represent a state of "good
>>> idea; still needs more work; contributions welcome" - which it
>>> arguably already does,
>>
>> I fully agree.
>>
>>> but it also includes many that should legitimately be obsoleted (not
>>> that it's worth anyone's time to figure out by what), reducing the
>>> signal-noise ratio.
>>
>> I'm not convinced of how much of a problem this acutally is, but it
>> seems to be considered as problematic by some, so I'm not going to
>> oppose it.
>>
>> With my XEP author hat on, I do have a Deferred XEP of my own (0379),
>> and my feeling is that it's not quite ready for Draft. Ideally, I would
>> like to let the Editor know that I want to keep it in Experimental for
>> some more time, and to gather additional feedback. The Editor is allowed
>> to move Deferred->Experimental ("Note that if a XEP is Deferred, the
>> XMPP Extensions Editor may at some point re-assign it to Experimental
>> status" in https://xmpp.org/extensions/xep-0001.html#approval-std).
>> There is no framework for *when* the Editor should or should not do
>> that, though. If Council and/or Board provide guidance to the Editors on
>> when this shall happen, and if e.g. an author can ask the Editor to do
>> just that, I'd be glad.
> 
> With my Editor hat on: I would like to avoid moving stuff from Deferred -> 
> Experimental in all but two cases:
> 
> (1) A non-editorial update was made
> 
> (2) As a step right before moving it to Proposed
> 
> Reason:
> 
> - Special-casing XEPs which the authors want in Experimental in the tooling 
> is 
> difficult, because it requires new metadata (i.e. changes to xep.dtd, 
> possibly 
> the xsl too, as well as xeplist.xml generation).

I can't follow. Don't we need to support Deferred → Experimental
already? Aren't we merely discussing potential causes for this state
change? And it appears author could already simply request the editor to
move a XEP back into Experimental, even without an textual change.


> - What even is the point of Deferred if authors can opt-out of it? Or rather, 
> what gain does Experimental bring an author aside from "it doesn’t look as 
> bad" (which I think it rightfully does)?

It signals that there is someone which cares enough that it stays in
Experimental. It appears to be very similar to what we do with the list
of clients/servers/libraries and hence it has a certain appeal to me.

- Florian



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

Re: [Standards] Tidying Deferred

[Jonas Schäfer]

Also replying to Goffi implicitly.

On Donnerstag, 17. Januar 2019 14:29:41 CET Georg Lukas wrote:
> * Tedd Sterr  [2019-01-16 21:50]:
> > My own preference would be for Deferred to represent a state of "good
> > idea; still needs more work; contributions welcome" - which it
> > arguably already does,
> 
> I fully agree.
> 
> > but it also includes many that should legitimately be obsoleted (not
> > that it's worth anyone's time to figure out by what), reducing the
> > signal-noise ratio.
> 
> I'm not convinced of how much of a problem this acutally is, but it
> seems to be considered as problematic by some, so I'm not going to
> oppose it.
> 
> With my XEP author hat on, I do have a Deferred XEP of my own (0379),
> and my feeling is that it's not quite ready for Draft. Ideally, I would
> like to let the Editor know that I want to keep it in Experimental for
> some more time, and to gather additional feedback. The Editor is allowed
> to move Deferred->Experimental ("Note that if a XEP is Deferred, the
> XMPP Extensions Editor may at some point re-assign it to Experimental
> status" in https://xmpp.org/extensions/xep-0001.html#approval-std).
> There is no framework for *when* the Editor should or should not do
> that, though. If Council and/or Board provide guidance to the Editors on
> when this shall happen, and if e.g. an author can ask the Editor to do
> just that, I'd be glad.

With my Editor hat on: I would like to avoid moving stuff from Deferred -> 
Experimental in all but two cases:

(1) A non-editorial update was made

(2) As a step right before moving it to Proposed

Reason:

- Special-casing XEPs which the authors want in Experimental in the tooling is 
difficult, because it requires new metadata (i.e. changes to xep.dtd, possibly 
the xsl too, as well as xeplist.xml generation).

- What even is the point of Deferred if authors can opt-out of it? Or rather, 
what gain does Experimental bring an author aside from "it doesn’t look as 
bad" (which I think it rightfully does)?

(I’d prefer to bury that idea right away.)

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Georg Lukas]

* Tedd Sterr  [2019-01-16 21:50]:
> My own preference would be for Deferred to represent a state of "good
> idea; still needs more work; contributions welcome" - which it
> arguably already does,

I fully agree.

> but it also includes many that should legitimately be obsoleted (not
> that it's worth anyone's time to figure out by what), reducing the
> signal-noise ratio.

I'm not convinced of how much of a problem this acutally is, but it
seems to be considered as problematic by some, so I'm not going to
oppose it.

With my XEP author hat on, I do have a Deferred XEP of my own (0379),
and my feeling is that it's not quite ready for Draft. Ideally, I would
like to let the Editor know that I want to keep it in Experimental for
some more time, and to gather additional feedback. The Editor is allowed
to move Deferred->Experimental ("Note that if a XEP is Deferred, the
XMPP Extensions Editor may at some point re-assign it to Experimental
status" in https://xmpp.org/extensions/xep-0001.html#approval-std).
There is no framework for *when* the Editor should or should not do
that, though. If Council and/or Board provide guidance to the Editors on
when this shall happen, and if e.g. an author can ask the Editor to do
just that, I'd be glad.

With my Council hat on, I don't know which XEPs have been actually
abandoned, and for which ones the author is just preparing a major
overhaul which we can not see. So I'm a bit hesitant on just casting
a vote on Deferred XEPs (but an LC should make the author respond).

In addition, I don't think it is a viable approach to have the Council
evaluate all Deferred XEPs for authors who can't be bothered to maintain
/ advance them any more.

I agree with the idea of crowd-sourcing the review of Deferred XEPs, and
to allow anyone to propose them for LC, with the LC resulting in either
of:

- Rejected or Obsolete (we have consensus that this is a dead end)
- Experimental with new author (if somebody volunteers to move it forward)
- stay in Deferred, because the exact status can not be determined.


Greetings,

Georg


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

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 12.43, Dave Cridland wrote:



On Thu, 17 Jan 2019 at 10:38, Ralph Meijer > wrote:


Unfortunately, XEP-0001 seems to require an updated version for moving
it out of Deferred back to Experimental. I doesn't seem a reasonable
requirement to need changes to move (indirectly) to Proposed:


I think this isn't quite right.


XEP-0001 says that a document moves back to Experimental if a new 
version is published, but implies elsewhere that a document might move 
there for other reasons, somewhat at the whim of the Editor.


I would argue that there are several reasons why a document might move 
out of Deferred and back to Experimental.


Our process should always match reality - and if Deferred merely means 
"forgotten about", or "nobdoy cares", then any clear indication that the 
community does care should cause it to move out.


I agree that the Editor can still do this, which is why we asked for 
XEP-0345. But apparently we need to make it clearer/explicit in XEP-0001.


Also, if the document moves out of Deferred to Experimental, without a 
change, I think tools/deferrals.py requires changes to prevent to move 
it back to Deferred, if only by adding a new version block.


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

Re: [Standards] Tidying Deferred

[Goffi]

Le jeudi 17 janvier 2019, 12:43:02 CET Dave Cridland a écrit :
> On Thu, 17 Jan 2019 at 10:38, Ralph Meijer  wrote:

> Our process should always match reality - and if Deferred merely means
> "forgotten about", or "nobdoy cares", then any clear indication that the
> community does care should cause it to move out.
> 
> Dave.
> 

In this case, could an author ask for a move back to experimental ? For 
instance by doing a PR to change the state ? Even if it's not the author it 
would be nice, there are a couple of Deferred XEPs I would like to see back to 
experimental (in the case of experimental means "nobody cares", otherwise I 
don't mind that XEPs are in Deferred state).

Goffi


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

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Thu, 17 Jan 2019 at 10:38, Ralph Meijer  wrote:

> Unfortunately, XEP-0001 seems to require an updated version for moving
> it out of Deferred back to Experimental. I doesn't seem a reasonable
> requirement to need changes to move (indirectly) to Proposed:
>
>
I think this isn't quite right.


XEP-0001 says that a document moves back to Experimental if a new version
is published, but implies elsewhere that a document might move there for
other reasons, somewhat at the whim of the Editor.

I would argue that there are several reasons why a document might move out
of Deferred and back to Experimental.

Our process should always match reality - and if Deferred merely means
"forgotten about", or "nobdoy cares", then any clear indication that the
community does care should cause it to move out.

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

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 11.25, Evgeny wrote:

On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland  wrote:
we do not require it until Final - not even Draft has an absolute 
requirement.


I thought transitioning to Draft requires Call For Implementors,
but whatever. Again this raises a question about how sane all
those XEP statuses nowadays. I know this is copied from IETF
workflow, but they have the same problems: a large number of RFCs
without implementations or with abandoned partial implementations.

But since the XSF standards development is severely understaffed
I think raising these questions makes even less sense (actually
this is true for almost any XSF workflow nowadays because of this).


I don't see large numbers of specifications being abandoned as a 
problem. It is a trove of thought experiments, some with code to go with 
it, that might be of use later. Leaving them as Deferred doesn't costs 
us anything.


I also want to note that the list of extensions [1] explicitly hides 
Deferred specifications by default to avoid distraction, based on 
similar earlier discussions.


[1] https://xmpp.org/extensions/

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

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 10.19, Ненахов Андрей wrote:

I'd suggest not accepting XEPs without any kind of existing technical
implementation in the future. If one suggests a standard extension, he
should provide a working software that supports it.


This is explicitly not how our standards process has been set up. The 
idea here is that having a published document as a starting point makes 
it more likely that people are not entrenched in particular early design 
choices, and discussion on those happen within the greater community.


Please have a good read of the rationale of the current process as 
defined in XEP-0001.


Implementations for gaining more experience are encouraged, but not 
required. The only transition that requires (2) implementations is from 
Draft to Final.



> Also, XEP-0333 Chat Markers should not belong to deferred. It is
> widely used in XMPP clients.

I agree that this specification should probably be Proposed to move to 
Draft.


The project I've been working on has gained us some insight and I think 
that there are some things that could be explained better. E.g. the 
interaction with message archiving.


--
ralphm


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

Re: [Standards] Tidying Deferred

[Ralph Meijer]

Replying to Dave and Goffi in one go:

On 17/01/2019 10.19, Goffi wrote:

Hello,

Le jeudi 17 janvier 2019, 09:55:17 CET Dave Cridland a écrit :

On Wed, 16 Jan 2019 at 20:48, Tedd Sterr  wrote:
Three things leap out at me:

1) Is it worth "cleaning Deferred"? That is, is having 177 documents in
Deferred state a problem?

2) If it is, our current solution to move them to some terminal, dead state
is to Last Call and then Reject them: (Deferred -> Experimental -> Proposed
-> Rejected). Is that OK? Does the community want 177 Last Calls of
pointless documents? Can the the Approving Body do this unilaterally (if, of 
course,
we allowed this in XEP-0001)?


I don't believe it makes sense to do that work for all Deferred 
specifications. It seems we can roughly divide all Deferred XEPs in a 
few categories:


1) More or less complete, considered of value, and maybe even has 
(multiple) implementations.


2) Considered of value, but needs more work to be accepted.

3) Interesting idea, but not pursued further.

Out of these, there are also cases where dependencies or dependents are 
still in flux (as Experimental), so that it doesn't necessarily make 
sense to advance them on their own (yet).


Especially XEPs of category 1 are candidates for moving to Draft. The 
biggest problem is that often the author seems to have abandoned the 
document before someone (the author or someone else) proposed the 
Approving Body (usually Council) to advance.


We should figure out if getting an Experimental XEP to Proposed requires 
the participation of the original author. I don't think this is needed.


Unfortunately, XEP-0001 seems to require an updated version for moving 
it out of Deferred back to Experimental. I doesn't seem a reasonable 
requirement to need changes to move (indirectly) to Proposed:


Given a spec that was last changed on January 18 2017, if someone had 
requested to advance to Draft yesterday, the Approving Body would have 
it in its queue for consideration and if deemed ready, it would issue a 
Last Call without changes. However, today, it would be Deferred, even 
though it might be just as ready as it was yesterday.


Therefore I think it should be possible to propose the Approving Body to 
advance a spec directly out of Deferred.


If the Approving Body doesn't deem it ready, the onus is on whoever 
would like to have it advance, to have changes made to meet the 
Approving Body's concerns. Such changes would make it take it out of 
Deferred, at which point it can be proposed again. This probably also 
solves the lack of an author.


If the Approving Body does deem it ready, the Editor should be able to 
do just that.


I want to note that last week the Editor was asked to move XEP-0345 
(Form of Membership Applications) to Proposed, even though it was 
Deferred, and issue a last call. This was requested by Board (which is 
also the Approving Body for this XEP), and has been honored.


Updating XEP-0001 to explicitly allow this route is probably a good idea.

I don't see the value of moving category 3 in any direction. These are 
usually not fully worked out, and having to move them to Rejected 
requires the Approving Body to make assumptions on what the full thing 
would look like. Just staying Deferred is just fine to me.




3) Finally, Tedd makes a very good point here in passing - the initial step
of skimming Deferred XEPs can be done by anyone in the community. While the
the Approving Body has to agree to put something into Last Call, anyone can 
request
that of the the Approving Body, as (in my guise as the Approving Body Chair) 
I'm happy to have
the the Approving Body vote on any Last Call as a general rule.


As mentioned above this seems to be what is meant by XEP-0001 as 
'deeming ready for advancement'. I strongly encourage people to let the 
respective Approving Bodies know which specifications they'd like to 
propose for advancement to Draft.




Note that some Deferred XEPs are actively used but either the authors are 
missing (that's more or less the case for XEP-0277 that Movim and SàT are using 
a lot), or the author wants time before moving (that's the case for 2 XEPs I've 
authored: XEP-0355 and XEP-0356: they are in a usable state, and I'm using 
them, but I plan to do changes on the long run and I feel it's too early to ask 
to move to draft).

In the first case, maybe there should be a way to change/extend the authors 
after some time (for instance edhelas or me could work on the XEP-0277).
For the later case, Deferred is a state that is OK for me, but I would not see 
the XEPs being killed (it's usable and used), I'm letting them in this state on 
purpose for the moment.


I believe in the absence of the original author, adding a new author 
that moves a XEP further along is just fine.


--
ralphm

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

Re: [Standards] Tidying Deferred

[Guus der Kinderen]

It would be good to see if we can find some unpolished gems in that stack
of deferred XEPs - thanks for bringing this up. I am, however, wondering if
making Council go through all deferred XEPs periodically is an effect way
to spend resources. If our goal is to revive those XEPs that are relevant,
I suggest that we instead:

   - Modify the warning text that is added to these XEPs (currently: "*WARNING:
   This document has been automatically Deferred after 12 months of inactivity
   in its previous Experimental state. Implementation of the protocol
   described herein is not recommended for production systems. However,
   exploratory implementations are encouraged to resume the standards
process.*")
   to include an invitation to resume work on the XEP, and a reference to a
   very accessible description on how that's done best. The goal here is to
   pull in people that are basing implementations on the XEP and like to see
   it advance, but don't necessarily know how to do that.
   - Periodically, and hopefully in an automated fashion, ping
   authors/contributors of deferred XEPs to ask them if they're interested in
   resuming work, or would like the XEP to be moved to a different state
   ('retracted', or 'obsolete' perhaps), which would make the pings stop. That
   way, council need only act on feedback from those pings, instead of weeding
   through the entire haystack.

On top of that, it'd be good to make people aware that, indeed, anyone can
ask Council to re-evaluate a particular XEP, as Dave and Tedd already
suggested.

Regards,

  Guus

On Thu, 17 Jan 2019 at 11:06, Dave Cridland  wrote:

>
>
> On Thu, 17 Jan 2019 at 09:19, Ненахов Андрей <
> andrew.nenak...@redsolution.ru> wrote:
>
>> I'd suggest not accepting XEPs without any kind of existing technical
>> implementation in the future. If one suggests a standard extension, he
>> should provide a working software that supports it.
>>
>>
> I'm highly against this. Our process is actually very clear on this -
> while we encourage implementation throughout, we do not require it until
> Final - not even Draft has an absolute requirement.
>
>
>> Also, XEP-0333 Chat Markers should not belong to deferred. It is
>> widely used in XMPP clients.
>>
>>
> Is that a request to Last Call it? Happy to put that on the Council agenda
> if you like.
>
>
>> --
>> Ненахов Андрей
>> Директор ООО "Редсолюшн" (Челябинск)
>> (351) 750-50-04
>> http://www.redsolution.ru
>> ___
>> 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] Tidying Deferred

[Evgeny]

On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland  
wrote:
we do not require it until Final - not even Draft has an absolute 
requirement.


I thought transitioning to Draft requires Call For Implementors,
but whatever. Again this raises a question about how sane all
those XEP statuses nowadays. I know this is copied from IETF
workflow, but they have the same problems: a large number of RFCs
without implementations or with abandoned partial implementations.

But since the XSF standards development is severely understaffed
I think raising these questions makes even less sense (actually
this is true for almost any XSF workflow nowadays because of this).

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

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Thu, 17 Jan 2019 at 09:19, Ненахов Андрей 
wrote:

> I'd suggest not accepting XEPs without any kind of existing technical
> implementation in the future. If one suggests a standard extension, he
> should provide a working software that supports it.
>
>
I'm highly against this. Our process is actually very clear on this - while
we encourage implementation throughout, we do not require it until Final -
not even Draft has an absolute requirement.


> Also, XEP-0333 Chat Markers should not belong to deferred. It is
> widely used in XMPP clients.
>
>
Is that a request to Last Call it? Happy to put that on the Council agenda
if you like.


> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> ___
> 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] Tidying Deferred

[Goffi]

Hello,

Le jeudi 17 janvier 2019, 09:55:17 CET Dave Cridland a écrit :
> On Wed, 16 Jan 2019 at 20:48, Tedd Sterr  wrote:
> Three things leap out at me:
> 
> 1) Is it worth "cleaning Deferred"? That is, is having 177 documents in
> Deferred state a problem?
> 
> 2) If it is, our current solution to move them to some terminal, dead state
> is to Last Call and then Reject them: (Deferred -> Experimental -> Proposed
> -> Rejected). Is that OK? Does the community want 177 Last Calls of
> pointless documents? Can the Council do this unilaterally (if, of course,
> we allowed this in XEP-0001)?
> 
> 3) Finally, Tedd makes a very good point here in passing - the initial step
> of skimming Deferred XEPs can be done by anyone in the community. While the
> Council has to agree to put something into Last Call, anyone can request
> that of the Council, as (in my guise as Council Chair) I'm happy to have
> the Council vote on any Last Call as a general rule.
> 
> Dave.
> 

Note that some Deferred XEPs are actively used but either the authors are 
missing (that's more or less the case for XEP-0277 that Movim and SàT are using 
a lot), or the author wants time before moving (that's the case for 2 XEPs I've 
authored: XEP-0355 and XEP-0356: they are in a usable state, and I'm using 
them, but I plan to do changes on the long run and I feel it's too early to ask 
to move to draft).

In the first case, maybe there should be a way to change/extend the authors 
after some time (for instance edhelas or me could work on the XEP-0277).
For the later case, Deferred is a state that is OK for me, but I would not see 
the XEPs being killed (it's usable and used), I'm letting them in this state on 
purpose for the moment.

++
Goffi


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

Re: [Standards] Tidying Deferred

[Ненахов Андрей]

I'd suggest not accepting XEPs without any kind of existing technical
implementation in the future. If one suggests a standard extension, he
should provide a working software that supports it.

Also, XEP-0333 Chat Markers should not belong to deferred. It is
widely used in XMPP clients.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Wed, 16 Jan 2019 at 20:48, Tedd Sterr  wrote:

> I think the first issue is to decide the actual purpose Deferred is meant
> to be serving - according to XEP-0001, that is essentially "was
> experimental, but has had no attention for 12 months;" I don't think anyone
> has a problem with that. The problem comes from nothing happening beyond
> this point; so there they sit: maybe they'll be resurrected, maybe they'll
> just rot. So now we have a huge pile of Deferred XEPs, some of which were
> temporarily left due to the author being otherwise busy, some of those
> subsequently fell off the radar, and others that were intentionally
> abandoned - with little way to tell the difference. Some people are content
> with this ("if the author cares enough, they can always pick it up again");
> others would like to at least remove the entirely-abandoned so it's easier
> to see what's actually relevant.
>
> Jonas's idea is to review one each week, but given that there are
> currently 177 Deferred XEPs, that would take 3.5 years (assuming 50 per
> year) and further months for the additional pile deferred since. Of course,
> doing several per week would be too much work, and a waste of effort that
> could be put to better use.
>
> My own preference would be for Deferred to represent a state of "good
> idea; still needs more work; contributions welcome" - which it arguably
> already does, but it also includes many that should legitimately be
> obsoleted (not that it's worth anyone's time to figure out by what),
> reducing the signal-noise ratio.
>
> For interest:
>  - 177 Deferred: 154 Standards, 19 Informational, 3 Historical, 1 SIG
>  - eldest: 16.5 years
>  - oldest 25%: 10.7+ years
>  - oldest 50%:  6.5+ years
>  - oldest 75%:  1.3+ years
>
> As a quick first pass, maybe we could take the oldest 25% (44 XEPs),
> community gives them a quick look over to decide whether they could ever
> have any possible minuscule interest, if so they make it known (no
> justification necessary, just the XEP numbers), and then after some
> appropriate period we say that the remainder can safely be rejected. I
> suspect the vast majority of these can be swept away as being no longer
> appropriate/relevant/interesting.
>


Thanks for this. As I said in the Council meeting yeserday, I really don't
care very much about Deferred XEPs which could be moved to a dead state. I
do, however, care about finding the XEPs which should be advanced (or just
revived). I could be persuaded that clearing out the dead wood might make
it easier to find the hidden gems.

Three things leap out at me:

1) Is it worth "cleaning Deferred"? That is, is having 177 documents in
Deferred state a problem?

2) If it is, our current solution to move them to some terminal, dead state
is to Last Call and then Reject them: (Deferred -> Experimental -> Proposed
-> Rejected). Is that OK? Does the community want 177 Last Calls of
pointless documents? Can the Council do this unilaterally (if, of course,
we allowed this in XEP-0001)?

3) Finally, Tedd makes a very good point here in passing - the initial step
of skimming Deferred XEPs can be done by anyone in the community. While the
Council has to agree to put something into Last Call, anyone can request
that of the Council, as (in my guise as Council Chair) I'm happy to have
the Council vote on any Last Call as a general rule.

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

[Standards] Tidying Deferred

[Tedd Sterr]

I think the first issue is to decide the actual purpose Deferred is meant to be 
serving - according to XEP-0001, that is essentially "was experimental, but has 
had no attention for 12 months;" I don't think anyone has a problem with that. 
The problem comes from nothing happening beyond this point; so there they sit: 
maybe they'll be resurrected, maybe they'll just rot. So now we have a huge 
pile of Deferred XEPs, some of which were temporarily left due to the author 
being otherwise busy, some of those subsequently fell off the radar, and others 
that were intentionally abandoned - with little way to tell the difference. 
Some people are content with this ("if the author cares enough, they can always 
pick it up again"); others would like to at least remove the entirely-abandoned 
so it's easier to see what's actually relevant.

Jonas's idea is to review one each week, but given that there are currently 177 
Deferred XEPs, that would take 3.5 years (assuming 50 per year) and further 
months for the additional pile deferred since. Of course, doing several per 
week would be too much work, and a waste of effort that could be put to better 
use.

My own preference would be for Deferred to represent a state of "good idea; 
still needs more work; contributions welcome" - which it arguably already does, 
but it also includes many that should legitimately be obsoleted (not that it's 
worth anyone's time to figure out by what), reducing the signal-noise ratio.

For interest:
 - 177 Deferred: 154 Standards, 19 Informational, 3 Historical, 1 SIG
 - eldest: 16.5 years
 - oldest 25%: 10.7+ years
 - oldest 50%:  6.5+ years
 - oldest 75%:  1.3+ years

As a quick first pass, maybe we could take the oldest 25% (44 XEPs), community 
gives them a quick look over to decide whether they could ever have any 
possible minuscule interest, if so they make it known (no justification 
necessary, just the XEP numbers), and then after some appropriate period we say 
that the remainder can safely be rejected. I suspect the vast majority of these 
can be swept away as being no longer appropriate/relevant/interesting.

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