XSF Discussion - 2024-03-28


  1. Daniel

    jcbrand: wrt the PR you just merged are you going to do the rest of the editor duties aka building the docker container and sending out notifications? Or in other words are you still active in your role as editor?

  2. jcbrand

    Daniel: I wasn't planning on it, but I'll do so

  3. Daniel

    jcbrand: no worries you don't have to. It's just that I generally prefer if only active editors merge stuff.

  4. Kev

    I have asked before for people to not merge unless they're going to do the whole script run.

  5. Daniel

    But I can send out notifications and stuff if you no longer have the tooling setup

  6. jcbrand

    Kev: does that apply to experimental xeps as well?

  7. Kev

    Yes.

  8. jcbrand

    Ok, sorry I'm a bit out of the loop

  9. jcbrand

    Daniel: that would be much appreciated

  10. Daniel

    There was probably a bit of miscommunication. I added you as a reviewer because I as editor wanted feedback from you as the author. Usually authors then don't have github permission to perform the merge. you only have that because you are still on the editor team

  11. Daniel

    At least permission wise

  12. Kev

    Ah.

  13. Daniel

    Not sure if you are still actively pursuing that position

  14. jonas’

    maybe it would be good to clean out inactive editors?

  15. jonas’

    and have iteam remove the permissions, too

  16. jonas’

    to avoid this kind of mishap

  17. Kev

    I think that would only leave Daniel and me (and I'm borderline), right?

  18. Kev

    I was about to make some sort of bus-factor argument, but then it's trivial to add people back into the permission list as needed, so I don't think it applies.

  19. Daniel

    > maybe it would be good to clean out inactive editors? Yes. I didn't want to ask board to kick of editors. But editors should maybe consider if the still want that role...

  20. Kev

    I think we could remove merge permissions from the inactives without Board interaction.

  21. Daniel

    I'm more than happy for Kev to stay both on the github permission list and on the xmpp.org website

  22. Daniel

    I trust he won't mess thinks up too bad 😉

  23. Daniel

    I trust he won't mess things up too bad 😉

  24. Kev

    The practical benefit, I think, is avoiding mishaps, and just limiting GitHub access without removing from 'the team' would solve that, for people who don't need it because they're not active.

  25. Kev

    > I trust he won't mess things up too bad 😉 I appreciate your mis-placed trust.

  26. Guus

    Please do not only modify permission lists. Lets have a specific list of who is editor, and update also the website listings accordingly.

  27. Guus

    and possibly any permissions with regards to access to inboxes, etc.

  28. moparisthebest

    > I have asked before for people to not merge unless they're going to do the whole script run. I mean, the correct fix is to have the merge do whatever is needed

  29. Kev

    > I mean, the correct fix is to have the merge do whatever is needed You're obviously not wrong.

  30. singpolyma

    I'm not sure if we want pr merges to auto send emails. But maybe

  31. Daniel

    >> I mean, the correct fix is to have the merge do whatever is needed > You're obviously not wrong. Yes. That doesn't mean anyone should be able to perform merges

  32. Kev

    Well, interestingly I don't seem to be smart enough to work out how to remove people from the team anyway.

  33. cal0pteryx

    > Please do not only modify permission lists. Lets have a specific list of who is editor, and update also the website listings accordingly. Guus: this list holds member infos and their roles. The website renders this list in several locations and ways https://github.com/xsf/xmpp.org/blob/master/data/members.json

  34. Guus

    cal0pteryx: I know. What I do not know is who is and isn't an editor these days.

  35. Guus

    I was trying to say that maybe we should first clear that up, and then update things accordingly.

  36. Kev

    This is the point.

  37. Kev

    Everyone is an Editor that has ever been an Editor unless explicitly removed.

  38. Kev

    (Or stood down)

  39. Kev

    It's not that we don't know who is an Editor, it's that the list of people who is an Editor is not useful.

  40. Guus

    Then lets remove that list.

  41. Guus

    I'd rather have no list if the alternative is a list that's wrong.

  42. Kev

    The list is not wrong.

  43. Kev

    (Or, at least, without checking it I don't suspect it is)

  44. Kev

    It's likely to be correct but unhelpful

  45. Daniel

    Remove everyone but Kev and me. List fixed?

  46. Guus

    Then there's no need to revoke access

  47. Guus

    https://xmpp.org/about/xsf/editor-team/

  48. Guus

    there's six people on there.

  49. Kev

    Indeed.

  50. Guus

    (corresponds to and is generated from the json blob that was linked to earlier)

  51. Kev

    And not all of those are doing work that requires merge access to the repo.

  52. Guus

    ugh, are you suggesting having distinct authorization for individuals that make up the team?

  53. Guus

    I had not considered that.

  54. Kev

    I'm suggesting that my taste for bureaucracy in chasing people to ask them to retire, or having Board (is it Board? I'd have to check) remove them is really limited, but there's a practical benefit to having people who don't need write access to the repo not having it.

  55. Kev

    And as the latter is easy to solve, why not do it.

  56. Guus

    I'd worry that this quickly escalates into an unmanageable mess, with some people having access, while others have not, almost arbitrarily. I'd prefer to strictly tie authorization to a role.

  57. Guus

    but not a hill for me to die on.

  58. Kev

    This is trivially reverted if it turns out that people do need access, so I've just done it.

  59. Kev

    And also mailed the Editors list so everyone knows what's happening.