XSF Editor Team - 2024-06-03


  1. larma

    https://github.com/xsf/xeps/pull/1346 < this PR was flagged by the bot as "Needs Council" because it was in Proposed state, but in my understanding, Proposed is essentially the same as Experimental and doesn't require Council to do changes (like incorporating feedback from last call), no? Should I adjust the tooling to have Proposed state act the same as Experimental and Deferred in that sense?

  2. larma

    https://github.com/xsf/xeps/pull/1346 < this PR was flagged by the bot as "Needs Council" because it was in Proposed state, but in my understanding, Proposed is essentially the same as Experimental and doesn't require Council to do changes (like incorporating feedback from last call), no? Should I create a PR to adjust the tooling to have Proposed state act the same as Experimental and Deferred in that sense?

  3. Kev

    I think leaving as-is is sensible for the moment, as changes aren't really meant to be made during Proposed. Editors can ignore the labels where it makes sense.

  4. Kev

    But if Daniel disagrees, just do whatever he wants :)

  5. Daniel

    How would one make changes that come up during last call?

  6. Daniel

    Go back to experimental first?

  7. Kev

    I should probably try to remember exactly what the process is meant to be.

  8. Daniel

    What I liked to do in the past is: last call ends. Council makes a decision on stable, back to experimental, or reject. However members of the current council seem to prefer 'leave it in last call until feedback that came up during last call is addressed'

  9. Daniel

    If the latter is something that becomes the regular process then authors should be able to make changes to proposed xeps

  10. Kev

    It's a specific version of the XEP that's proposed. So my reading of 1 is really that it should be moved back to experimental, or rejected. Then a new version can be proposed if needed.

  11. Kev

    A XEP should only be in Proposed while it's under LC or a Council vote, according to 1.

  12. larma

    I understand the process from XEP 1 https://xmpp.org/extensions/xep-0001.html#proposal as follows: 1. XEP author requests advancement of XEP (not a specific revision) 2. Council starts Last Call through Vote 3. Editor puts the XEP in Proposed 4.1. 14 days or more of last call 4.2. XEP author incorporates all feedback from last call 5. Editor proposes XEP at specific revision to Council 6. Council votes on specific revision So as long as 5 didn't happen, it's perfectly fine to do changes to Proposed XEPs.

  13. larma

    But honestly the current Proposed state is a little weird, as it is effectively two states "Last Call" and "Council Vote"

  14. larma

    So the solution is to add a new state "Calling" when the last Call starts and "Proposed" when the current revision is proposed for vote. In Proposed we wouldn't allow changes, in Calling we would.

  15. Kev

    TBH, I don't think there's any value in having a state for either LC or CV.

  16. Kev

    Or, well, not very much value, at least.

  17. larma

    Well at least CV is good to have for automation purposes

  18. larma

    So that Daniel doesn't need to think if the bot was right to claim it needs the council to merge the PR

  19. Kev

    If we have LC we probably want both LC and CV. I was proposing getting rid of both.