XSF Editor Team - 2020-03-02


  1. pep.

    jonas’, do you have a list of things you'd like to see done by editors, I'm thinking tooling mostly

  2. jonas’

    registry

  3. pep.

    Or infra

  4. jonas’

    registry

  5. pep.

    yeah registry

  6. jonas’

    xeps themselves are manageable

  7. jonas’

    it’s currently blocking on iteam

  8. jonas’

    AFAIK

  9. pep.

    I know, so it's not in my power really :/

  10. jonas’

    you can do editorial work on the registries

  11. jonas’

    like checking the content of the XMLs against the XEPs

  12. jonas’

    they haven’t been updated in at least three years

  13. pep.

    Ok so tooling for that would be a thing to do

  14. jonas’

    I don’t think you can do tooling for that

  15. jonas’

    but go ahead

  16. pep.

    Just curious

  17. jonas’

    one could try to scrape the registry submissions from the documents

  18. jonas’

    but that sounds error-prone

  19. pep.

    What else?

  20. jonas’

    do it manually

  21. pep.

    I mean what else could use tooling

  22. jonas’

    I don’t think one can create tooling for this which won’t fail silently or have lots of false positives

  23. jonas’

    I don’t know

  24. jonas’

    I’m happy with the current tooling

  25. pep.

    k

  26. jonas’

    except that I’d like to automate email sending, but that mostly requires infrastructure

  27. jonas’

    or faster build processes, but that also requires infrastructure

  28. jonas’

    I fix most pain points in the tooling myself

  29. jonas’

    I should proablby commit my scripts to create tags though

  30. jonas’

    there are a few nice-to-haves

  31. jonas’

    I guess

  32. jonas’

    like a bot which analyses new PRs and automatically assigns labels (ProtoXEP, Needs Council, Needs Author, Needs Board)

  33. pep.

    Yeah that's also something I wanted

  34. jonas’

    something which creates and maintains a todo list for editors, because it’s not always clear what needs to be done

  35. jonas’

    and my attempt at introducing Github Projects for that was shot down

  36. pep.

    yeah

  37. jonas’

    which is a shame, because they even got more automation for those nowadays

  38. pep.

    shot down by whom?

  39. jonas’

    someone from the Editor team

  40. jonas’

    check the commit history

  41. jonas’

    of README.md

  42. pep.

    ok

  43. pep.

    Well now that you're managing editors almost by yourself..

  44. pep.

    I'm not personally against it

  45. jonas’

    I also effectively was back then

  46. pep.

    That would tie us even more to github, but I don't see us moving any time soon as much as I would like it

  47. jonas’

    for what reason?

  48. pep.

    me wanting to move?

  49. jonas’

    yes

  50. pep.

    I had that clear in mind some time ago. I'd say one of the biggest reason now is because I'm generally not fond of big hubs

  51. jonas’

    we don’t have the resources to host our own.

  52. pep.

    I'm aware of that, which is why I'm saying I don't see us moving to that

  53. jonas’

    so there’s no reason to not make use of the platform we currently have

  54. pep.

    We agree

  55. jonas’

    right

  56. Kev

    jonas’: The XSF is in GSoC this year. I wonder if one could wrangle a XEP management platform as a project

  57. Kev

    The email automation thing I think can be done with 'moderate' ease (hours of coding rather than weeks), by recording the last-announced versions of everything and the current versions, and sending emails on container startup if they differ. But I'm not volunteering, I'm afraid.

  58. pep.

    I don't think that's a good idea. GSoC takes quite some time for mentors if done properly, more than if we were to do it ourselves

  59. jonas’

    Kev, the email thing is essentially just a webhook and two lines of code. or one line of code if you do it on the XSF server which knows when stuff has happened either way.

  60. jonas’

    but frankly, email sending is least of my concernsn