XMPP Council - 2023-02-28

  1. tmolitor

    I like to put PR #1215 on the council agenda: https://github.com/xsf/xeps/pull/1215

  2. daniel

    IIRC council pretty much pre-approved this change (at least saying it is in the right general direction) but wanted to wait until the xeps that this depend on have been updated

  3. tmolitor

    okay, next week then, I hope...

  4. daniel

    There is a slight awkwardness with SM then depending on an experimental xep. Which personally I think I'd be fine with because it's a dependency that could be reversed. Alternatively it shouldn't be too difficult to last call sasl2 (and maybe bind 2)

  5. daniel

    Either way I think we first need an editor to do something as we can't last call a xep that hasn't been published

  6. daniel

    Last calling bind2 and sasl2 soonish might be a good thing to do anyway and sm depending on it could give us the extra incentive

  7. tmolitor

    keep in mind that the SASL2 framework consists of XEP-0388 AND this protoxep not yet moved to the inbox: https://github.com/xsf/xeps/pull/1248

  8. daniel

    Kev: I think 424 and 425 can be moved back to experimental given their unsuccessful last call

  9. daniel

    I don't know if there is a procedure...

  10. Zash


  11. Kev

    Zash is technically correct.

  12. daniel

    Or one could argue that the author is currently applying last call feedback.

  13. larma

    > If the Approving Body decides after Last Call that the XEP is not ready for advancement yet, but nevertheless useful, it can vote to move it back to Experimental state.

  14. larma

    we have to vote šŸ™‚

  15. Zash

    Yes, lets pause everything for a few months to implement a new XEP state, "ApplyingLastCallFeedback" ! :D

  16. daniel

    OK. We'll vote on it tomorrow

  17. Kev

    Would Council be ok with replying on GitHub post-vote, or would that not work as a scheme? I'm aware that with both Peter and Me acting as Editor at the moment a mail to just one of us doesn't really work. Come to think of it, I should have included Peter in that mail to council@ as well.

  18. daniel

    I can reply on Github

  19. Kev

    Thanks, Daniel.

  20. Kev

    So if I'm following what Link Mauve's saying on https://github.com/xsf/xeps/pull/1269/commits/f8351a86e28c28063bdbc29d2f3495f0d59f2c5b correctly, they submitted a protoXEP. Edhelas submitted changes to it while it was still in the inbox, adding themselves as an Author, and it was merged without Link Mauve being asked, and it was (consequently ?) rejected. Link Mauve now wants to revert it to its original state as they submitted it, make some changes, and have it reconsidered. This seems like something it would be expedient for Council to just say "Go ahead and merge that, Kev", because this feels messy and Council have more authority than me.

  21. Link Mauve

    Iā€™m just resubmitting the first version under a different track (Historical this time).

  22. daniel

    The cop-out would be to just give it a new short name

  23. daniel

    Then neither council nor editor needs to figure out what went wrong in the past

  24. daniel

    But 'just merge it Kev' is likely fine too

  25. daniel

    The outcome (documenting what we currently doing with muc avatars without saying anything about pubsub) is a good thing

  26. Kev

    Merged it anyway, edhelas replied.