XSF Discussion - 2020-06-18

  1. dada


  2. MattJ

    We have a board meeting in 1h40m... would appreciate someone to step up as minute-taker ahead of time so we don't spend half the meeting on that again

  3. MattJ

    I have most of a bot implemented, but not going to suggest we rush to use it this week (it needs a little more polish)

  4. MattJ

    Answering the discussion from last night, no, the bot does not summarize discussions - many organisation minutes do not, and only record actual motions and other things explicitly requested to go on the record

  5. MattJ

    So the bot does this, but with links to the discussion logs of each topic

  6. MattJ

    Which seems a fine compromise to me

  7. MattJ

    Summarizing discussions accurately is one of the hardest tasks of minute-taking

  8. MattJ

    We have the advantage that all our discussions are already in text form and recorded

  9. pep.

    probably most important

  10. pep.

    the whole point of minutes to me is for people not to have to read the logs

  11. MattJ

    I'd rather let people see the outcome, and give them access to the raw data, rather than filtering through some other person

  12. MattJ

    It's very easy for someone to introduce accidental bias this way (related problem: we don't explicitly approve minutes currently)

  13. pep.

    well yes that's why approving minutes is necessary

  14. Zash

    Standard practice afaik is to have one minute taker and two to verify and sign off on the minutes.

  15. MattJ

    We can't even find one person to write the minutes :)

  16. MattJ

    and this has been going on for years

  17. MattJ

    They aren't going to magically appear - and we've tried alternatives (thanks nyco) where everyone collaborates on them, that didn't really work either though

  18. jonas’

    I’ll be stuck in a work meeting until 15:00Z, sorry

  19. MattJ

    np jonas’

  20. pep.

    MattJ: I was on the pad helping nyco a bit. maybe if we'd all done so..

  21. MattJ

    Sure, maybe if many things

  22. MattJ

    If we collectively think that's the solution, I'm not opposed to trying it again

  23. jcbrand

    IMO, the XSF should consider paying for certain roles/positions that we continuously struggle to get volunteers for (touchy subject I know)

  24. pep.

    jcbrand: I agree

  25. jcbrand

    Or provide some other kinds of incentive, but I can't imagine what... swag?

  26. jcbrand

    Or provide some other kind of incentive, but I can't imagine what... swag?

  27. pep.

    either that, or board takes responsability for it and we all contribute (we've agreed about one way to do this last week but there might be others)

  28. MattJ


  29. MattJ

    Personally I strongly feel that a bot is the best approach

  30. MattJ

    I think I'm alone in that though

  31. Seve

    MattJ: I'm with you on this, I agree on all you have said

  32. jcbrand

    Someone needs to write a bot then

  33. MattJ

    As above, I have one almost completed (but not ready to use this week)

  34. MattJ

    and I'm not going to attempt to push it on the group if everyone else is against it

  35. jcbrand

    ah sorry

  36. jcbrand

    You could just enable it silently and then show everyone the awesome minutes that it takes

  37. jcbrand

    and then bask in glory

  38. MattJ

    Yeah, have pondered that :)

  39. flow

    jcbrand, do we have enough income to pay someone? how much could we pay someone? do we have someone who manages our funds?

  40. Zash

    The IETF, while a fair bit larger than the XSF, does hire out administrative tasks to a company.

  41. Seve

    We have the raw data, and the outcome with the bot. It is perfect, less layers to access to what has happened. I have nothing more to say to what it has been already said by MattJ. I see it as a perfect fit.

  42. Guus

    (Don't have time to read back, but I have no strong feelings either way about using a bot)

  43. MattJ

    Hopefully by next week I'll have the bot polished off and some docs written, and then I'll propose that we switch to it

  44. jcbrand

    flow: Last I heard there are funds, although the XSF could definitely make more of an effort to woo sponsors

  45. jcbrand

    The point is not to make someone rich or to provide a full-time job, but to at least make the task more palatable

  46. flow

    jcbrand, we sure have funds, but what can be spend on reappearing payments? also I think before we can seriously consider payming someone, we should look for a treasurer, cause I am not sure if PSA has the time to take care of that

  47. MattJ

    Did I mention I'll be offering the bot for a small fee?

  48. MattJ

    (muahaaha, etc.)

  49. jcbrand


  50. jcbrand

    If it's a once-off fee, then it's better than paying a human to do it

  51. jcbrand

    flow my understanding is that the XSF has been sitting on cash for year, not really doing anything with it

  52. Guus

    flow we do have a treasurer, Peter.

  53. jcbrand

    flow my understanding is that the XSF has been sitting on cash for years, not really doing anything with it

  54. flow

    Guus, I know, but only beause of our search for a new treasurer did not yield any results.

  55. Guus

    I have no inclination to dismiss his work or to assume that he's not able to perform in that role.

  56. pep.

    Guus: il sure that's not what flow is saying

  57. pep.

    Guus: i'm sure that's not what flow is saying

  58. Guus

    no, we searched for a new Executive Officer (which was also Peter). We never searched for a new Treasurer, afiak.

  59. flow

    Guus, no, not at all, but I think that peter would actually be happy if someone else would fill that role

  60. MattJ

    Was just typing what Guus said

  61. flow

    Guus, we searched for a treasurer in 2015: https://mail.jabber.org/pipermail/members/2015-July/008117.html

  62. Guus

    I did not know that. But, since, Peter was asked to stand for another year repeatedly, and has never objected or mentioned he'd prefer someone else took over.

  63. flow

    I'd speculate that this caused by a mix of it being currently not that mutch work (I assume) and the expectation that there is no one to step in

  64. Guus

    Hey, if he does want someone else to take over, I'm perfectly happy to search for someone else. I'd just not postpone any other activity in the assumption that we need to refill the Treasurer role, as the person that's currently in that role did not give any indication that that's relevant.

  65. flow

    My suggestion would be to ask peter of he is still willing to act as treasurer if we increase the workload

  66. flow

    that's all

  67. Guus

    right, we're more aligned than it initially appeared to me. 🙂

  68. Guus

    I don't think Peter will be silent if the work load becomes more than he's happy with.

  69. MattJ

    I'll just prep another plugin for the bot in that case ;)

  70. Zash

    Heh, I was going to suggest that. Bots are better with numbers after all :P

  71. MattJ

    Yes, Lua has great floating point support

  72. MattJ

    What could go wrong?

  73. MattJ

    !spend €400

  74. pep.

    fwiw I have suggested going through SPI before (to handle finance, and they also provide legal council etc.), to stpeter at least, maybe that's something we can think about

  75. MattJ

    Actually that would be something I could get behind if necessary

  76. pep.

    They don't do minute taking yet

  77. Guus

    I wonder how much autonomy we give up by going through a party like SPI. I have yet to look into that deeper.

  78. pep.


  79. Seve

    Hello, all good?

  80. MattJ

    Hello :)

  81. Guus

  82. MattJ

    ralphm, ?

  83. MattJ

    (or is this a week he sent apologies?)

  84. Guus

    did he? I missed it if he did.

  85. MattJ

    Seems not

  86. MattJ

    Ok, I can step up if ralphm is absent

  87. Guus

    please do

  88. pep.


  89. MattJ

    0) Role call

  90. Seve

    Very appreciated

  91. Guus


  92. MattJ


  93. pep.


  94. Guus


  95. Seve says hi

  96. MattJ

    Let's start with

  97. MattJ

    1) Topics for decisions

  98. Guus


  99. MattJ

    1.1) Reevaluate the process for accepting XEP contributions

  100. MattJ

    Looks like https://trello.com/c/Y4Bfcnr3/399-reevaluate-the-process-for-accepting-xep-contributions from jonas’

  101. MattJ

    (I'll send out minutes after the meeting)

  102. pep.


  103. Guus

    Jonas asks if we got legal council on the necessity of the (CLA) process.

  104. Guus

    I do not know.

  105. Seve

    Hate to say this but neither do I

  106. Guus

    I was involved in setting up the CLA bot, but only because it was a pending issue ('to-be-done')

  107. pep.

    What was before github?

  108. Guus

    I've looked back in my personal mail archive, but couldn't find much of a motive for this.

  109. pep.

    And how did people agree to the IPR

  110. Guus

    no, that was on github.

  111. MattJ

    I think it was implicit before Github

  112. pep.

    I'm asking about before github

  113. MattJ

    Not sure if the editor kept any records, not that I'm aware (but stpeter would know)

  114. pep.


  115. MattJ

    None of us are lawyers, though in my experience a lawyer's opinion on something like this tends to usually just be an opinion and "maybe"

  116. Seve

    Who can we reach to resolve "Q1"? (Actually confirm if we can ignore that step from the process)

  117. Guus

    I think we'll not get an answer with the people in this meeting. 🙂 Let's find someone who was involved at the time?

  118. MattJ

    Obviously having an explicit ack from the contributor is good for our records, should an issue arise

  119. Seve


  120. MattJ

    If we don't have that, I can see it being problematic if there ever was a dispute

  121. pep.

    jonas’ and I can go through standard discussions about switching to github and we may find why/who decided

  122. pep.

    But getting hints from someone who knows would be good

  123. pep.

    MattJ, sure but ACKs can take different forms

  124. MattJ


  125. Guus

    oh, shoot.

  126. Guus

    I'm only now reading the rest of Jonas' question

  127. MattJ

    I'd be fine with any alternative to the bot if that's what we want

  128. Guus

    it was below a fold in trello

  129. Guus


  130. jonas’

    13:39:04 pep.> And how did people agree to the IPR email

  131. jonas’

    13:39:44 MattJ> Not sure if the editor kept any records, not that I'm aware (but stpeter would know) I kept records for all users which did it via email

  132. jonas’

    (with me)

  133. MattJ

    Also, I may not be up to date on the latest on this thread, but I think we may not necessarily be moving off Github anyway?

  134. jonas’

    (there were one or two cases since I became editor which were handled via email)

  135. MattJ

    jonas’, thanks, good to know

  136. jonas’

    MattJ, clabot is a blocker for moving off gitlab, and I’m swaying towards "do a hybrid solution as a testballoon, long term Gitlab primary"

  137. jonas’

    MattJ, clabot is a blocker for moving off github, and I’m swaying towards "do a hybrid solution as a testballoon, long term Gitlab primary"

  138. MattJ

    I'd be more comfortable if we kept an explicit IPR acknowledgement from contributors about IPR, I'm absolutely fine with any solution for that

  139. pep.

    As an editor I'd also prefer if we didn't have two venues as a long term goal

  140. Guus

    I think that getting clarification from a lawyer on this is both costly and time-consuming.

  141. Guus

    I'd suggest to find a way to not make this issue a blocker for other editor-process improvements.

  142. jonas’

    ok, so let’s skip the "did we get counsel" and move on to "what do you think about my proposed alternatives"

  143. jonas’

    (please read the card until the bottom :))

  144. MattJ

    I'm fine with the proposed alternatives

  145. jonas’

    Q2 specifically :)

  146. MattJ

    As you say, this is all info made public on contribution anyway

  147. Seve

    I like that is based on git

  148. MattJ

    Lawyers hate it ;)

  149. Seve

    heh :)

  150. MattJ

    GDPR issues, if someone wanted to be forgotten

  151. jonas’

    I’d like to have Board-ack on the option in Q2. Though we could also find a way to make the list non-public if board is uncomfortable with having a blatant list of PII world-readable on gitlab

  152. Seve

    Good point

  153. MattJ

    But I consider that a rare enough event that we can cross that bridge when/if we ever need to

  154. pep.

    Yeah.. I'm happy with sign-off but I'd like legal council tbh. It's not like we hadn't had contributions from companies with money in the past that could actually use this against us

  155. jonas’

    note that right for deletion is guarded by technical feasibility, only the right to rectification is unconditional.

  156. MattJ

    If anything, part of the acknowledgement should be that their info will be public in our repos

  157. jonas’


  158. MattJ

    So make that explicit, and I'm in

  159. jonas’

    maybe Board can make a motion on that :)

  160. jonas’

    and then I’ll do things

  161. Guus

    I don't want to vote on things now.

  162. Guus

    I desperately want more feedback on this

  163. jonas’

    (and I’m back in my $work meeting)

  164. MattJ

    Feedback from?

  165. MattJ

    Thanks jonas’

  166. Guus

    at least from (seniors in the) community, and possibly legal council.

  167. MattJ

    What exactly concerns you?

  168. Guus

    I don't like changing things that I'm unsure of why they were put in place in the first place.

  169. MattJ

    CLAs are quite common

  170. Guus

    as pep. hinted, legal repercussions _might_ be severe.

  171. MattJ

    and their purpose is well understood

  172. MattJ

    I don't understand

  173. MattJ

    There are two questions here... 1) do we need a CLA? 2) how do we process the CLA?

  174. MattJ

    My answers are (1) yes (2) however we want to

  175. Seve

    I just see moving from confirming on an email to a commit message? (excluding the clabot)

  176. MattJ

    clabot is not mandated by lawyers

  177. MattJ

    Most won't even know what it is

  178. MattJ

    It's just a convenient thing someone made

  179. pep.

    My answers are (1) maaaybe? and (2) We should get legal council to confirm that method is fine

  180. MattJ

    So if you're concerned about moving away from that, I don't think that's justified

  181. Guus

    Right - I'm a lot less uncomfortable if we're not discussing the necessity of a CLA.

  182. MattJ

    I'm quite sure we didn't get legal counsel on whether clabot was acceptable

  183. Guus

    I'm happy to use another technical ways to replace clabot.

  184. Guus

    (to do the exact same thing, record the CLA)

  185. MattJ

    Plenty of other orgs do CLAs through other means, some insist on written signed forms

  186. pep.

    MattJ, re clabot, being a commonly used service I'd hope they have had legal council themselves, or they've been put to the test already.

  187. MattJ

    Many lawyers will probably will tell you that's necessary

  188. MattJ

    You only have to convince a court that someone had agreed to the IPR terms

  189. pep.

    I think I can draw a parallel to security here. Put as many resources to protect against what you think you'll have to face

  190. MattJ

    If we don't have any process, and it's implicit, I think that's very hard

  191. pep.

    I think I can draw a parallel to security here. Put as much resources to protect against what you think you'll have to face

  192. MattJ

    If we have any kind of paper trail, then we're good

  193. MattJ

    (and paper includes email in this case)

  194. MattJ

    e.g. that's one concern - if we migrate off Github do we lose the CLAs of previous contributors?

  195. MattJ

    Ok, we're approaching full time

  196. Guus

    cla-assistent lets you export them, if memory serves

  197. MattJ

    Looks like we don't have enough to vote on, but maybe folks can think about this issue more and we can vote next week

  198. Kev

    FWIW, as I remember the history here, we used to assert that just having submitted a commit was sufficient (that the contribution to the repo itself was enough). A prior board decided there had to be an explicit step added, so an explicit step was added.

  199. pep.

    Guus, I'm curious to know if an export is sufficient in court. Or if cla-assistant signs it or something

  200. Seve

    Kev, thank you

  201. Kev

    I think that's about the extent of what happened. I don't *believe* the Board got counsel, but I might be wrong.

  202. Guus

    Thanks Kev

  203. MattJ

    Ok, I don't see anything else on the agenda that's new, pressing, or that we'd have time to discuss, so I propose we close here

  204. pep.


  205. Guus


  206. MattJ

    2) Time of next

  207. MattJ


  208. MattJ

    3) Close

  209. MattJ

    Thanks all

  210. Guus


  211. Guus


  212. pep.


  213. Seve

    Thank you MattJ !

  214. Seve

    It really helps to know that, thank you Kev

  215. Kev

    It's just my migraine-addled memory, I wouldn't take it as gospel :)

  216. Seve


  217. Kev

    I mean, the first part is definitely (as sure as I can be) right. We used to just assert that by contribuing a XEP that said in it (once XSL was applied) that it was owned by the XSF that meant the author was assigning ownership to the XSF, and it was definitely decided to change that because it wasn't deemed safe.

  218. Kev

    The details of the decision process during the change are a bit fuzzier for me.

  219. MattJ

    Minutes sent

  220. Guus


  221. jonas’

    Thanks Board

  222. jonas’

    that was useful as a guideline

  223. jonas’

    The rough consensus that we do want a process which gets us an affirmative ACK is already important to me. Replacing CLAbot as a tool I don’t think is a problem in general, since it can’t do any magic either.

  224. jonas’

    We’ll find a similarly powerful replacement for the GitLab platform, the process I outlined would be an example of that.

  225. jonas’

    regarding exporting the "signatures" of cla-assistant, I don’t think that’s of much use since they’re tied to github users, which is not quite a thing on GitLab ;)

  226. jonas’

    though I guess we can restore some manually (and I’d be happy to) for the common contributors so they don’t have to go through the hassle; in the end, the cardinality of authors is rather low

  227. pep.

    jonas’, they're useful though as a proof that existing contributors have ACK'd

  228. Zash

    Assuming it's only a one-time thing maybe that's okay as a way to test that it's not too annoying then?

  229. jonas’

    Zash, what would be okay?

  230. jonas’

    (dangling reference in "that's okay as a way")

  231. Zash

    in-reply-to: "though I guess we can restore some [clabot signatures] [...] for the common contributors so they don’t have to go through the hassle"

  232. jonas’

    Zash, so you would not do that to check with the common contributors if the process looks alright?

  233. pep.

    Yeah I'm also fine with re-signing. It's only a one-time thing anyway

  234. pep.


  235. jonas’

    I see

  236. pep.

    It's one less (legally?) error-prone thing for editors to do as well

  237. jonas’


  238. Zash

    jonas’, I got the impression that we might find a replacement clabot thing. if that turns out too annoying to subject previous contributors to, then isn't it too annoying?

  239. jonas’

    very true

  240. jonas’

    good point you make

  241. Kev

    Of the barriers that might be present in moving to gitlab purely for me, I wouldn't think going through the CLABot process again that problematic (assuming it was no harder than the current one).

  242. Kev

    (Other aspects might be, but not that one)

  243. Zash

    or "if that turns out so annoying that it's worth it to try to export previous data, then"

  244. Zash

    vacation mode. brain turned off.

  245. pep.

    disregarding of whether we want to restore ACKs, do we not have to keep an export?

  246. pep.

    disregarding whether we want to restore ACKs, do we not have to keep an export?

  247. Zash

    could argue that it's implied in the merging of the PR

  248. pep.

    It was already decided to go with explicit ACK (and I agree with that)

  249. Zash

    if you assume in good faith that the bot did its job

  250. jonas’

    I’d still want an export for safety

  251. pep.

    Though I'm not sure I understand your sentence, Zash

  252. jonas’

    if github folds, we don’t have a record of what happened in the PR

  253. jonas’

    and that clabot required anythign

  254. pep.


  255. jonas’

    and that clabot required anything

  256. pep.

    Though we'll always be dependent on github anyway..

  257. pep.

    Because if they fold we lose the identity provider

  258. pep.

    (for these signatures)

  259. pep.

    We'd need to ensure the export contains email addresses rather

  260. pep.

    (and then we'd only depend on gmail)

  261. Zash

    What's that, identity is Hard? :)

  262. jonas’

    I created an export and it does not include the email

  263. jonas’

    it only includes user name + id

  264. Kev

    I'm not sure we need the email, I suspect we /do/ need the name.

  265. pep.

    I'd say we need something that binds to an identity. I doubt "we" (the XSF) need to know the full legal name. Just like I never gave that to github

  266. jonas’

    > Using emojis in names seems fun, but please try to set a status message instead pah, gitlab.

  267. jonas’

    (I do appreciate that they have a separate error message for that though :))

  268. !XSF_Martin

    Pah, XMPP… It also doesn't allow emoji in nicks.

  269. pep.

    "It depends"

  270. !XSF_Martin

    On what?

  271. jonas’

    on how lenient things are in enforcing or on how RFC 7622 they are

  272. vanitasvitae

    how good is XEP-0238: Moved adopted in clients?

  273. vanitasvitae

    I mean, are there many clients implementing that XEP?

  274. Neustradamus

    vanitasvitae: the XEP is https://xmpp.org/extensions/xep-0283.html