XSF Discussion - 2022-11-04


  1. emus

    I think it should happen. as always I am happy to support organisation

  2. goffi

    vanitasvitae: hi. re: XEP-0396 (JET-OMEMO), how would you send the transport secret with TWOMEMO (which has not KeyTransportElements)? Would not a simple XML element with TK + IV suffice as we can use SCE with TWOMEMO? I've made the implementation with OLDMEMO, but I would like to handle TWOMEMO too.

  3. goffi

    and on an other topic, is there any progress regarding editor troubles? If we end-up without editor in January, we'll have a serious problem. It seems that the board has some money to hire somebody to make the requested improvments, can't we do that?

  4. MattJ

    Who to hire, and what should they do?

  5. jonas’

    MattJ, emus and others worked on making a list of actionable and roughly scored issues in xsf/xeps

  6. jonas’

    ideally, we'd hire someone from the community who already has an idea what they're doing

  7. MattJ

    I was about to say, I don't think what we have is enough to hand over to someone outside the community who is unfamiliar with the process

  8. MattJ

    (or we could, but it would waste a lot of time and resources)

  9. jonas’

    yes, certainly.

  10. jonas’

    they'd first have to read through '1

  11. jonas’

    on the other hand, a fresh mind would maybe clean up a lot of things :)

  12. MattJ

    https://github.com/xsf/xeps/issues is a laundry list of random stuff, where to start?

  13. jonas’

    1223--1227 are the important ones

  14. jonas’

    we could label those with a high-priority label

  15. MattJ

    I'll create an "Editor Tooling" label or something

  16. jonas’

    ack

  17. MattJ

    Okay: https://github.com/xsf/xeps/issues?q=is%3Aissue+is%3Aopen+label%3A%22Editor+Tooling%22

  18. Ge0rG

    jonas’: I hesitated to explicitly ping you in those tickets to get additional details on what should be implemented, but you helpfully linked to the editor process document.

  19. jonas’

    yeah, there was a round-trip via the board ML which I can read as board<>council liaison

  20. Ge0rG

    MattJ: 1227 is "Editor Tooling" too

  21. jonas’

    Ge0rG, it is indeed (and already labelled as such)

  22. Ge0rG

    nevermind

  23. Ge0rG

    looks like my websocket lagged

  24. emus

    maybe board can review what I was writing to them and tell whats feasible

  25. Daniel

    Can we hire jonas’? 🤯

  26. jonas’

    Daniel, I don't want to go through the troubles of that, being employed.

  27. jonas’

    Daniel, I don't want to go through the troubles of that, being employed elsewhere already.

  28. Daniel

    jonas’, the troubles of actually doing the work or the trouble of setting up the system to get paid?

  29. jonas’

    the latter certainly

  30. jonas’

    I'm not sure about the former

  31. Kev

    If we can make an ordered and refined backlog (for anyone who doesn’t hate such terms), I can *try* to do something.

  32. jonas’

    Kev, https://github.com/xsf/xeps/issues?q=is%3Aissue+is%3Aopen+label%3A%22Editor+Tooling%22

  33. jonas’

    that's the relevant backlog

  34. jonas’

    I could put an ordering on that, it is already partially refined, I guess it could use more of that

  35. Kev

    Ok. Let’s see if I have any energy on my two hour train trip coming up. Long week.

  36. MattJ

    FWIW I'm currently working on CI plumbing. What's currently missing are some of the tools to run in it, such as linting and sanity checks, mail notifications, etc.

  37. Kev

    Does that mean you have a grasp on what should be happening?

  38. MattJ

    I don't know if anyone else is doing anything else, though thilo.molitor has expressed an interest

  39. Kev

    Basically, if there’s something I can do within my 2H window, given train wifi, I can try to do it.

  40. MattJ

    I'm just trying to focus on one small thing at a time, so generally the answer is "no"

  41. MattJ

    I started on what I'm doing because if we have the tools to do what we need, we need to be able to run them somewhere

  42. MattJ

    so I'm working on that foundation first

  43. Kev

    Do we already have tooling that knows about committed changes, for example? Which XEPs have been changed, anything like that?

  44. MattJ

    No, but that could definitely be extracted from what I'm currently doing

  45. MattJ

    So if anyone works on a tool that needs that info, just define an input format for that and I can generate it

  46. Kev

    I’m thinking a script that gets run on container startup, diffs XEPs compared to a cache of previous run, sees which have changed version and triggers “I need a mail” from that.

  47. Zash

    MattJ, seen tools/md-diff.sh ? :)

  48. MattJ

    Consider the diff generation part of what I'm already working on, but nothing more than that

  49. MattJ

    Zash, not in working memory

  50. Kev

    Ok. I think I’d probably better not try and do anything right now, it sounds like I’m going to just duplicate effort.

  51. vanitasvitae

    goffi: I haven't yet found the time to take a look at JET+TWOMEMO, but using SCE sounds reasonable

  52. goffi

    vanitasvitae: alright, I may use my own element for now, and I'll update once the XEP is updated.

  53. vanitasvitae

    Since you have a working implementation, you might be in a better position than me in terms of collecting real world experience :D

  54. vanitasvitae

    So feel free to experiment with your own element and then (if I don't come around to it earlier) ping me, so we can copy your element into the XEP :P

  55. goffi

    OK thanks.

  56. MattJ

    Kev, that's why I'm trying to be explicit about what I'm *not* working on (and one reason I haven't previously announced that I'm working on anything). I'd rather not have the burden of editor tooling fall solely onto me, just because I made a start...

  57. Zash

    You're the editor now, dog.

  58. MattJ

    🤦

  59. Kev

    AFAICS, if we want to automate attic generation reliably, we're going to want to enforce squashing PRs.

  60. Kev

    Unless we're going to be happy (which I think is reasonable, but maybe others don't) with a script the Editor can run when they're ready to trigger publication of new XEPs that would populate the attic, add git tags etc., and then push the result.

  61. jonas’

    Kev, I wish for git tags on revision blocks, and those can be detected in diffs / by comparing xeplist.xml on different revisions

  62. jonas’

    Kev, I wish for git tags on revision blocks, and those can be detected/auto-generated in diffs / by comparing xeplist.xml on different revisions

  63. jonas’

    so all we need to enforce that there are no changes to a file in a PR after the commit which adds a revision block

  64. Kev

    So the logic you want is a script that will: foreach xep in *.xml: extract ver if not check attic for ver: git tag copy to attic commit attic push to attic and xeps.git ?

  65. Kev

    Not that I seem to have enough bandwidth to checkout xeps.git to do anything with it at the moment, annoyingly.

  66. jonas’

    you don'- need to if not check attic for ver, you'd diff the old and new master

  67. Kev

    I was hoping to make something easy by making it stateless outside of the repos (i.e. doesn't need to know about git diffs).

  68. MattJ

    It gets tricky. Git itself doesn't even have the concept of a "PR". Determining if "no changes to a file in a PR are made after the commit which adds a revision block" is not super trivial (but I don't think it's impossible)

  69. Kev

    I don't think I'll have the inclination to fiddle with git like that, but I'll try to capture it in the github ticket at least for anyone who does want to try it.

  70. pep.

    fwiw, not talking about editors specifically, but while volunteering is great, and if somebody has time and motivation for it, I'm all for it, but I also wouldn't want to burn people out ("because otherwise we're gonna have to pay") and I'd rather lean towards paying someone to alleviate the pain.

  71. pep.

    Because there is money, and there could be more money if we put money in it.

  72. pep.

    (yeah it's all about money..)

  73. jonas’

    MattJ, that's why I said it should be a github integration

  74. emus

    why not use the fiscal hosting instead of hiring?

  75. singpolyma

    emus: something still has to hire someone :)

  76. emus

    butbI thought no hiring is required

  77. emus

    you put a budget

  78. singpolyma

    Budgets don't do work. You have to pay them to a human ;)

  79. moparisthebest

    I can automate things with bash, but where are they running? in github actions or ?

  80. moparisthebest

    I really hate working with proprietary CIs because they just change or go away at their whim

  81. emus

    singpolyma: you psy the hours estimated

  82. singpolyma

    moparisthebest: any script you write for one CI will work in another generally. They're mostly the same

  83. emus

    folks, its serious. And its not easy. I see that but we need to get different paths going here. I can only strongly encourage this. if people invest their hours vountarily and get tasks done, why not for some compensation...

  84. moparisthebest

    singpolyma: nope they all have different variables they set with branch names, they all run in different contexts etc etc, it's a nightmare

  85. singpolyma

    moparisthebest: sure, so don't rely on any of that

  86. singpolyma

    I've moved stuff from Travis to sorucehut without any changes usually

  87. moparisthebest

    Specifically the "push, wait for test to run, repush, repeat" dev cycle is the nightmare

  88. MattJ

    For most things you should be able to dev and test locally

  89. MattJ

    In any case, yes, go ahead and use bash... where they are running shouldn't be a concern

  90. Daniel

    emus: the issue is that the XSF can't just randomly wire people money. They have to invoice first. And to send invoices you need to setup a legal entity that's allowed to do that. And then file taxes

  91. Daniel

    That's a lot of work for someone who is employed and doesn't have such a legal entity setup

  92. Zash

    Oh glob the taxes! And the *reverse* VAT! 😱️

  93. singpolyma

    Daniel: really, you have to do all that where you are?

  94. Daniel

    singpolyma: you don't?

  95. singpolyma

    Here people do freelance work without any special legal entity all the time

  96. singpolyma

    It's jus part of your personal income taxes

  97. MattJ

    You can do the same in the UK

  98. lovetox

    yeah Daniel, i dont think tis *that* complicated ..

  99. lovetox

    if its in some normal range of income

  100. MattJ

    It has a lot of drawbacks compared to setting up an entity, but plenty of people do it

  101. Daniel

    It's not that complicated. But I can understand why someone doesn't want to deal with it

  102. lovetox

    if it exceeds some amount it gets more complicated

  103. lovetox

    i understand that its a lot of overhead for someone who does no contract work at all

  104. lovetox

    and is just employee somewhere

  105. singpolyma

    I honestly have even done freelance without invoices, but I understand some kinds of entities need the invoices to pay so I write them when asked

  106. lovetox

    there is some initial overhead

  107. lovetox

    but if you hire someone who does that kind of work, then its not really more overhead for them

  108. singpolyma

    The hard part is finding the person and hiring them :)

  109. Daniel

    Well that moves the overhead to the XSF.

  110. Daniel

    And who's going to do that?

  111. Daniel

    If you actually employ them I mean

  112. singpolyma

    No, don't do employer stuff for sure, especially cross border that's sometimes weird

  113. emus

    Daniel i get your point, but i dont know how to solve it '...

  114. emus

    but we need a solution