XMPP Council - 2024-03-05


  1. daniel

    It's time

  2. daniel

    1) roll call

  3. dan.caseley

    Hi!

  4. larma

    ๐Ÿ‘‹๏ธ

  5. moparisthebest

    Hello!

  6. singpolyma

    Hi

  7. daniel

    2) agenda bashing

  8. daniel

    I didnโ€™t send one out but we've been asked to talk about https://github.com/xsf/xmpp.org/pull/1331#issuecomment-1975271650 iโ€™ll do that in the voting section

  9. daniel

    3) Editors update

  10. daniel

    none

  11. daniel

    4) Items for voting

  12. daniel

    there is https://github.com/xsf/xmpp.org/pull/1331

  13. daniel

    iโ€™m skeptical this is even something we should decide tbh

  14. moparisthebest

    I'm +1 on PR1331, in some future where we are better about not letting used things slip into Deferred we can revert it

  15. dan.caseley

    I think it makes sense for Council. We regularly make decisions on behalf of the consumers of XEPs.

  16. daniel

    if we were to decide on that iโ€™m personally leaning towards 0 or -1

  17. moparisthebest

    I also have no idea whether that's ours to decide :)

  18. singpolyma

    Can someone remind me which one this is

  19. Kev

    Does it need Council? No. Is Council's opinion worth having on this? Sure.

  20. dan.caseley

    > Can someone remind me which one this is Defaulting "Deferred" checkbox to on in the xmpp.org XEP picker.

  21. daniel

    singpolyma, the PR? it about making the 'search deferred' checkbox on the xep search/overview be checked by default

  22. daniel

    i mean on one hand it's so minor that the website people should just figure that out

  23. larma

    As per definition, a Deferred XEP is an Experimental XEP that wasn't updated for 12 months. As such for almost all purposes, they should be treated the same IMO

  24. singpolyma

    Ah right that one. I agree this isn't really us, deferred in principle should mean do not look but in practise thats not currently true always...

  25. daniel

    but if I were the website people i would probably say no

  26. singpolyma

    Which is on us to improve I guess

  27. moparisthebest

    That

  28. daniel

    > As per definition, a Deferred XEP is an Experimental XEP that wasn't updated for 12 months. As such for almost all purposes, they should be treated the same IMO i mean yes. but it also means that apparently nobody is actively working on it or cares enough about it to let it advance to stable

  29. dan.caseley

    I'm in favour of enabling more and letting the user filter down, at least until we have confidence in XEP states. +1

  30. daniel

    not in every single instance of course

  31. moparisthebest

    In theory, in practice it's often widely deployed

  32. daniel

    ok. should we leave it as that? every council member has now voiced there opinion and the website people take it from there?

  33. moparisthebest

    And/or a dependency for things that are widely deployed

  34. moparisthebest

    > ok. should we leave it as that? every council member has now voiced there opinion and the website people take it from there? +1 :)

  35. dan.caseley

    ๐Ÿ˜‚

  36. daniel

    ok. moving on then

  37. daniel

    5) Pending votes

  38. daniel

    moparisthebest, pending on the two items from last week

  39. daniel

    Proposed XMPP Extension: Host Meta 2 (with PR #1323) XEP-0313: Add XEP-0136 to superseded specifications

  40. moparisthebest

    +1 to host meta 2 obviously :D

  41. moparisthebest

    The other... On list or here later...

  42. daniel

    ok

  43. daniel

    6) Date of Next

  44. singpolyma

    +1w wfm

  45. daniel

    +1w wfm

  46. moparisthebest

    +1w wfm

  47. dan.caseley

    Ditto

  48. larma

    +1w wfm

  49. daniel

    7) AOB

  50. larma

    Maybe the uncertainty of what Deferred is supposed to mean could be considered a reason to question and reconsider the purpose of this state...

  51. daniel

    is it uncertain? I think as a mechanism the intention is fairly clear. is it working well in a fairly inactive community? maybe not

  52. moparisthebest

    I tend to agree with larma there

  53. larma

    - If there are things in Deferred where Council feels it needs more work to advance, we should either nag the author to do that or appoint a document sheppard to do it - If there are things in Deferred where Council feels it should advance, we should nag the author to start a last call to advance or appoint a document sheppard to do so - If there are things in Deferred where Council feels they are not worth considering any further, we should nag the author to either retract or start a last call to reject if necessary, or appoint a document sheppard to do so

  54. larma

    For every XEP in Deferred, there is an action that should be taken, rendering the state redundant except to tell everyone that we're not doing our job.

  55. MattJ

    What is the correct "Done for now, but waiting for implementations" state?

  56. MSavoritias (fae,ve)

    experimental?

  57. MattJ

    Because that's the state many of our pre-stable XEPs are in

  58. Zash

    Having a state that's ฦ’(state, timedelta(last change, now)) does seem a touch redundant.

  59. MattJ

    So then we end up with a bunch of XEPs in Experimental, even if nobody is actively pursuing them

  60. daniel

    > What is the correct "Done for now, but waiting for implementations" state? _technically_ stable

  61. MattJ

    daniel, really? Not sure about reaching stable with no implementations...

  62. larma

    What is the reason that there is no implementation? Because whatever is the reason should be a reason to change the XEP.

  63. MSavoritias (fae,ve)

    but stable cant change easily no?

  64. Zash

    MattJ, you're probably thinking of Final n

  65. Zash

    MattJ, you're probably thinking of Final

  66. MattJ

    larma, sometimes developers just have other things to do first

  67. larma

    In which case it might be worth to retract (or not propose in first place)

  68. larma

    Because apparently the author doesn't want the XEP to be considered at this point

  69. MattJ

    Just because I'm working on it right now, I'll use spam as an example: we have a bunch of anti-spam-related XEPs, and nobody has implemented them for years. They're not wrong, but also I wouldn't consider them good quality for "stable" until they've been implemented.

  70. daniel

    mhhh ok I donโ€™t think we are going to get to any decision during this council meeting. i donโ€™t see us voting on abolishing deferred. so let's end the council meeting and open a wider debate on that

    ๐Ÿ‘Œ๏ธ 1
  71. MattJ

    But I'm using what I can from the prior work that was done, in my implementation(s)

  72. moparisthebest

    for sure

  73. daniel

    8) Close on the council meeting. Thank you see you next week. but feel free to stay around for the 'Deferred' discussion

  74. larma

    MattJ, if you are not considering it good quality for stable, isn't it fair to say that you want "to remove the XEP from further consideration in the XSF's standards process"

  75. larma

    MattJ, if you are not considering it good quality for stable, isn't it fair to say that you want "to remove the XEP from further consideration in the XSF's standards process"?

  76. MattJ

    No, because now that the XEP has implementation it will likely be good to revive it

  77. moparisthebest

    daniel: thanks!

  78. MSavoritias (fae,ve)

    not having it visible in the xmpp.org is problematic.

  79. MSavoritias (fae,ve)

    as an experimental

  80. MSavoritias (fae,ve)

    because it duplicates work at the very least

  81. moparisthebest

    MSavoritias (fae,ve): everything is visible, this is just about checkbox defaults

  82. MSavoritias (fae,ve)

    ah. never mind then

  83. singpolyma

    TBF i mostly disagree with accepting experimental with zero implementations also

  84. MSavoritias (fae,ve)

    i am all for a rethink of the xeps states as a whole

  85. MSavoritias (fae,ve)

    including yeah not accepting experimental without implementations

  86. Zash

    There's no implementation requirement for Stable tho

  87. singpolyma

    The problem isn't the deferred with no impl though, the problem is deferred widh many impl

  88. MattJ

    +1

  89. MattJ

    +100

  90. Zash

    ๐Ÿ’ฏ๏ธ

  91. MSavoritias (fae,ve)

    i think thats a xep states problem. not just a checkbox imo. because who wants to point at a "deferred" xep as a recomendation

  92. Zash

    Abolish states!

  93. daniel

    I guess the entire process is not working as originally intented for many different reasons

  94. MSavoritias (fae,ve)

    adding a deferred by default solves the problem of visibility

  95. MSavoritias (fae,ve)

    but it doesnt solve that i need to fix a typo every year to keep it experimental

  96. MSavoritias (fae,ve)

    for some reason

  97. larma

    MSavoritias (fae,ve), don't fix typos, propose for last call instead!

  98. MSavoritias (fae,ve)

    but then it gets stable and nobody can change it easily :/

  99. moparisthebest

    > The problem isn't the deferred with no impl though, the problem is deferred widh many impl This, and ideally we fix. But until we do it's probably sensible to include them in the search by default

  100. singpolyma

    Yeah. I need to revisit my list of important experimental and deferred xeps and propose another LC

  101. MSavoritias (fae,ve)

    also if its only one implementation i cant get it to stable

  102. MSavoritias (fae,ve)

    it would be wrong

  103. larma

    > but then it gets stable and nobody can change it easily :/ If you want people to implement it, it shouldn't be changed easily, because it won't be easy to change implementations

  104. singpolyma

    Already we see cases of complaints when an experimental xep changes because lots of production stuff is using it. It's a hard balance but I think there are a few we can move. But it's on me to propose which

  105. larma

    Also, last call is for people to raise concerns so that things are adjusted before it goes to Stable

  106. MattJ

    I think I'm fine with removing Deferred

  107. Kev

    Or keep it and remove the auto.

  108. MattJ

    But we probably want to make some other changes if we do that

  109. MattJ

    Kev, yeah, I think that would be fine

  110. MattJ

    "Archived", "Snoozed", ...

  111. Kev

    "Mute for 12 months" :)

  112. moparisthebest

    Hehe I like it

  113. Zash

    There are only two relevant states: - Not Implemented - Implemented

  114. MSavoritias (fae,ve)

    -obsolete

  115. MattJ

    And then regarding the website, I think these XEPs would be in Experimental, but the website could visually indicate XEPs that are Experimental with no implementations

  116. MSavoritias (fae,ve)

    agreed

  117. moparisthebest

    Ideally council would go through the whole list of currently expirimental/deferred every year and sort them into active/used/not-used whatever those states might be

  118. larma

    As we're automating editor work: We can have an email sent to all authors of Deferred XEPs at the 1st of each month. And then they will want to either find and fix a typo (or even more) or retract the XEP to no longer be spammed for those mails.

  119. Zash

    Hm. (not) implemented ร— (don't) implement

  120. larma

    As we're automating editor work: We can have an email sent to all authors of Deferred XEPs at the 1st of each month. And then they will want to either find and fix a typo (or even more) to get back to Experimental or retract the XEP to no longer be spammed for those mails.

  121. Kev

    I think it's just one more thing that a community with more available energy could achieve. Whether this is the area we should be applying our energy is another question.

  122. Kev

    > As we're automating editor work: We can have an email sent to all authors of Deferred XEPs at the 1st of each month. And then they will want to either find and fix a typo (or even more) to get back to Experimental or retract the XEP to no longer be spammed for those mails. That sounds activeely harmful.

  123. Kev

    > As we're automating editor work: We can have an email sent to all authors of Deferred XEPs at the 1st of each month. And then they will want to either find and fix a typo (or even more) to get back to Experimental or retract the XEP to no longer be spammed for those mails. That sounds actively harmful.

  124. MSavoritias (fae,ve)

    yeah no please dont

  125. MattJ

    Removing (auto) Deferred will reduce work and automation requirements, so that makes me happy

  126. MattJ

    Instead we would just do the equivalent on the frontend

  127. Zash

    Can still render Experimental progressively ... some way the older it gets?

  128. larma

    So how is Deferred reached then if it's not automated?

  129. MattJ

    It's like "retracted" but softer

  130. larma

    So it's decided by the author

  131. MattJ

    and maybe named "inactive" or something

  132. MattJ

    Yeah, but it's not a terminal state

  133. MattJ

    Just "I'm not working on this"

  134. larma

    some sort of "please don't show me in the list of XEPs anymore"?

  135. MattJ

    Right

  136. larma

    some sort of "please don't show me in the list of XEPs anymore, but I will likely revise in the future"?

  137. MattJ

    We may not need this state, but if we had it, that's what it would be

  138. Zash

    Experimental, Not changed for 1 year, zero implementations?

  139. MattJ

    But just as helpful would be Council advancing these: https://data.xmpp.net/explore/xmpp/deferred

  140. MattJ

    No point in discussing process improvements that are more work to implement than that

  141. moparisthebest

    > Instead we would just do the equivalent on the frontend I like this, with more doaps could actually be very nice "date of latest implementation" or whatever

  142. MattJ

    When we render the XEPs we can add flags like: (!) This XEP has been inactive for more than 12 months (!) This XEP has no known implementations

    ๐Ÿ‘๏ธ 1
  143. MattJ

    That's more clear than trying to let people figure out what it means for a XEP to be "deferred"

  144. MSavoritias (fae,ve)

    +1

  145. moparisthebest

    We already have "click here for implementations" which is most of it

  146. moparisthebest

    And a number without a click

  147. daniel

    Fwiw I own two of the widely implemented deferred xeps and I intent to fix this

  148. MattJ

    334 is mine, but IIRC people weren't keen on it last time advancement was brought up

  149. MattJ

    Meanwhile it gained more and more implementations and seems to be working as intended

  150. moparisthebest

    Many used implementations in the wild trumps any naysayers imho...

  151. MSavoritias (fae,ve)

    could it be that the whole problem is we give a number? if they didnt have a number and stayed in inbox until they were stable would we care?

  152. MSavoritias (fae,ve)

    or is that proposed? im confused

  153. MattJ

    Yes, not giving them a number has been proposed before, and it's basically how the IETF does it

  154. MattJ

    But would we just end up with a bunch of implemented XEPs in inbox?

  155. MSavoritias (fae,ve)

    if they are not stable then yeah probably

  156. pep.

    > If you want people to implement it, it shouldn't be changed easily, because it won't be easy to change implementations And then you're killing off early experimentations. Because yes it's still "early" after a year of not doing anything on it

  157. MSavoritias (fae,ve)

    its early as long as the implementations are less than 3 imo

  158. MSavoritias (fae,ve)

    and also less than 2 different languages at least

  159. pep.

    > (!) This XEP has been inactive for more than 12 months > (!) This XEP has no known implementations What about this but "still worth having such a feature so it should stay discoverable so that someone else can pick it up instead of rewriting the world"

  160. MSavoritias (fae,ve)

    > But would we just end up with a bunch of implemented XEPs in inbox? but the whole inbox then probably doesnt make sense in that case no

  161. MSavoritias (fae,ve)

    > But would we just end up with a bunch of implemented XEPs in inbox? but the whole inbox then probably doesnt make sense in that case no?

  162. MattJ

    Then people will host XEPs on their sites (like https://xeps.tigase.net/ ) and we lose the discoverability

  163. MSavoritias (fae,ve)

    im not proposing not to show them on the website

  164. MSavoritias (fae,ve)

    another question: can i make my xep "Active" instead of stable?

  165. pep.

    fwiw I'd even like to upload stuff like https://bouah.net/specs/mentions.html somewhere on an XSF server so that it's there for grabs. I have said multiple times I don't intend to work on this anymore but I do this it's still relevant

  166. pep.

    I've linked it in the past multiple times so that people know it's there.

  167. pep.

    I do think* it's still relevant

  168. MattJ

    MSavoritias (fae,ve), "Active" is basically the name that non-technical XEPs use instead of "Stable"

  169. MSavoritias (fae,ve)

    a space in the site that says "orphan xeps" or something would be nice for that

  170. pep.

    Should I submit it? It depends on a non-accepted PR for 0372, and it's certainly going to end up Deferred.

  171. MSavoritias (fae,ve)

    where people can see xeps that are not being worked on and are just there

  172. MSavoritias (fae,ve)

    > MSavoritias (fae,ve), "Active" is basically the name that non-technical XEPs use instead of "Stable" ah ok

  173. pep.

    Should I submit it? It depends on a not-yet-accepted PR for 0372, and it's certainly going to end up Deferred.

  174. MattJ

    Specifically, per https://xmpp.org/extensions/xep-0001.html#types - anything that defines protocols would be considered "Standards Track", the other types of XEP don't follow the same path as those ones

  175. MattJ

    https://xmpp.org/extensions/xep-0001.html#states-Active

  176. singpolyma

    > MSavoritias (fae,ve), "Active" is basically the name that non-technical XEPs use instead of "Stable" Reminder that stable is a funny name for draft ๐Ÿ˜‰

  177. MSavoritias (fae,ve)

    what oO

  178. pep.

    Yeah.. Stable was Draft not so long ago

  179. MSavoritias (fae,ve)

    so proposed is the early access or something :P

  180. MSavoritias (fae,ve)

    what was stable stable then? that doesnt change. or it doesnt exist

  181. pep.

    There was no Stable before.

  182. singpolyma

    It was just a rename to the state

  183. Zash

    IETF has something like draft โ†’ EXPERIMENTAL RFC โ†’ draft-bis โ†’ PROPOSED RFC โ†’ draft-again??? โ†’ ULTIMATE RFC ???

  184. singpolyma

    Because people didn't understand draft state meant you should use it

  185. MSavoritias (fae,ve)

    sounds like the deffered problem all over again

  186. pep.

    Still happy to have suggestions re my "mentions" draft above fwiw

  187. pep.

    Two different people asking about features like this in the last two weeks, and more before.

  188. moparisthebest

    Note IETF's procedures don't appear to be working that well either, what with most development happening on GitHub or w3.org or whatever

  189. MSavoritias (fae,ve)

    thats not because of numbers tho. its a culture issue

  190. Zash

    Where work on drafts happen doesn't matter to IETF, anymore than it matters to the XSF what text editor you use on your computer when XEPing?