XSF Discussion - 2020-04-30

  1. pep.


  2. pep.

    Guus, MattJ, ralphm, Seve

  3. Seve


  4. ralphm bangs gavel

  5. ralphm

    0. Welcome + Agenda

  6. ralphm

    Hi, who do we have?

  7. MattJ


  8. ralphm

    Beyond what's been added to Trello, any other topics to discuss?

  9. pep.

    Not from me

  10. ralphm

    1. Minute taker

  11. pep.

    Not me this time

  12. Guus

    Sorry, I"m here!

  13. Guus

    I can do the minutes

  14. pep.


  15. Guus

    No additional agenda items for me

  16. ralphm

    2. Member opinion

  17. ralphm


  18. pep.


  19. ralphm

    Flow is asking in the context of "adopt-a-character". He would like to poll members and is thinking about using https://civs.cs.cornell.edu/. This requires email addresses though to be able to limit to one vote per person. He asks if he can get members' email addresses."

  20. pep.

    Flow was asking how to perform member opinion votes. He'd like to use https://civs.cs.cornell.edu/ (condorcet voting service) but that requires members' emails

  21. ralphm

    I don't think we can do this.

  22. pep.

    Which, the xsf having no privacy policy..

  23. pep.

    I am personally keen on trying out this voting method, but I'm not exactly fond of giving away members' emails, yes

  24. jonas’

    can we implement concordet in memberbot?

  25. pep.

    "not today"

  26. pep.

    But eventually that'd be ideal

  27. jonas’

    well we can’t give away email addresses today either ;)

  28. ralphm

    Doesn't mean we can in fact just give out member's e-mail addresses. Even without a policy, I'm pretty sure it violates, among others, the GDPR.

  29. jonas’

    can we have memberbot collect votes and put the votes in an existing concordet tool?

  30. jonas’

    without passing on PII

  31. ralphm

    I think Alex can rig up memberbot, but I'm unsure what you still need concordet for afterwards

  32. pep.

    ralphm, if we had a privacy policy saying we use third-partyXX to do voting and they require email addresses for this specific reason (which is a very valid reason tbh), we wouldn't be violating GDPR

  33. Guus

    I feel strongly about not giving out members email addresses to a third, unless they choose to supplied it themselves (like we do with the dinner signup form).

  34. Guus

    I feel strongly about not giving out members email addresses to a third party, unless they choose to supplied it themselves (like we do with the dinner signup form).

  35. jonas’

    ralphm, concordet is a voting scheme beyond a simple majority vote

  36. pep.

    Guus, well there we use google forms, it's not really better :P While I'm free to not answer that form, it's a requirement for me to go to the dinner

  37. pep.

    Guus, well there we use google forms, it's not really better :P While I'm free not to answer that form, it's a requirement for me to go to the dinner

  38. ralphm

    pep., regarding dinner, nobody's raised issues around that before. If they had, we'd have accomodated.

  39. Guus

    at the very least, it's not the XSF supplying the mail addresses.

  40. pep.

    I've asked multiple times not to use gforms yes, ralphm

  41. Guus

    (and what he said)

  42. Guus

    let's not get into that right now.

  43. pep.


  44. Guus

    but focus on the voting stuff.

  45. Guus

    is it feasible to create / adapt a bot for this?

  46. pep.

    It surely is

  47. Guus

    also: do we _need_ a fully fault tolerant / highly secure voting mechanism for something that's basically an advice on picking a pretty picture?

  48. Guus

    maybe we're overengineering this?

  49. pep.

    Guus, that's beyond the point

  50. pep.

    It's mostly to try out the method

  51. MattJ

    Feels like scope creep to me :)

  52. pep.

    Some of us would like to change our voting system within the XSF and that's a perfect way to test it

  53. jonas’

    I’m with pep that trying a voting method for a non-critical vote is better than trying it first in a membership/council/board vote ;)

  54. Guus

    Oh, I'm perfectly happy for using it as a testbed.

  55. MattJ

    But this is indeed a low-priority issue as far as I'm concerned, so if it gets stuck behind a memberbot rewrite I'm not going to complain too much

  56. pep.

    Ok so, "stuck being a bot rewrite" is our answer?

  57. pep.

    At least we can clearly answer "no" to giving away members' emails

  58. Guus

    but, the issue at hand: will XSF give out its members email addresses.

  59. Guus


  60. Guus

    Might be good to not require the bot rewrite for the membership advice to happen.

  61. pep.

    Either we adapt a bot, or we setup a voting service on our infra

  62. Guus

    Might be good to not require the bot rewrite for the membership advice (on the adopt-a-character thingy) to happen.

  63. pep. rolls eyes

  64. pep.

    I guess that's this sorted anyway.

  65. ralphm

    3. member.json

  66. ralphm

    Is this about https://xmpp.org/about/xsf/members.html?\

  67. ralphm

    Is this about https://xmpp.org/about/xsf/members.html?

  68. pep.


  69. ralphm

    Then you should raise this with Alex.

  70. Guus

    if not correct, provide PR? It seems to be maintained pretty regularly - but there's always a chance of an error slipping through.

  71. ralphm


  72. pep.

    Ah I have an AOB from Flow regarding members.json (just remembered)

  73. ralphm

    pep., different from this?

  74. pep.


  75. ralphm

    If you want, we can do it here?

  76. pep.

    Ah ok, I was waiting for AOBs. Sure

  77. pep.

    Privacy concerns, fullname stays in git even after being removed.

  78. pep.

    I am personally not sure what to do about this or if it's a concern at all. GDPR-related

  79. pep.

    And other privacy laws

  80. jonas’

    hm, I’d say the fullname stays in mailing list archives, too, as well as wiki. Of course, those can be redacted, while redacting the git would be ... painful

  81. pep.


  82. ralphm

    I don't really know if we can or should do something about this.

  83. pep.

    In the meantime, maybe we could have a privacy policy though to be aplicit about this

  84. pep.

    In the meantime, maybe we could have a privacy policy though to be explicit about this

  85. ralphm

    pep., didn't you start on one long time ago?

  86. pep.


  87. ralphm


  88. pep.

    There were some efforts re GDPR

  89. pep.

    But it's not for the membership

  90. pep.

    It's for XMPP services

  91. ralphm


  92. pep.

    Which the XSF could also have fwiw

  93. pep.

    Which the XSF could also use fwiw

  94. ralphm

    I agree we should have one. It might be good to have some legal advice before we publish one, though.

  95. pep.

    I don't think I am the right person to do this tbh. Someday(tm) can surely list things that the XSF does re privacy, but then shouldn't we need legal advice

  96. pep.

    Yes :)

  97. ralphm

    Anyone have access to someone?

  98. pep.

    Not off-hand. I can poke around but I don't expect much

  99. ralphm


  100. Guus

    Winfried maybe?

  101. ralphm

    Guus: good call

  102. Guus

    isn't that up his alley?

  103. Guus

    unsure if he's available for this, but we can ask/

  104. ralphm

    4. Commitments

  105. pep.

    Somebody(tm)* (why "someday"..)

  106. pep.

    Guus, can you ask? Should I ask

  107. Guus

    could you?

  108. ralphm

    I've sent out the e-mails, have gotten one response, who would revisit in a few months.

  109. pep.

    Guus, k

  110. Guus


  111. pep.

    re comms person, I'd like to clarify some bits

  112. ralphm

    I haven't heard back about my contact for communications.

  113. ralphm


  114. pep.

    Ok I was kinda feeling blocked about this. I got strong hints that we didn't want to bother with contracting as long as it wasn't "necessary". And at the same time you announced you might have someone. So I wasn't entirely sure what to do

  115. pep.

    I also haven't heard back from anyone, so I'll try to do another round of poking to different people.

  116. ralphm


  117. ralphm

    As for not wanting to bother, setting up a contracting relationship is not my expertise, so I am not sure what would be involved. If someone were to offer services in kind as a form of sponsorship, that would indeed make things a bunch easier.

  118. ralphm

    So it is not that I don't /want/ to.

  119. pep.

    I think that's a "skill" that we should acquire one way or another, as it will come in handy. It can also "just" be contracting a party that does contracting for us.

  120. MattJ

    My contact would likely want to freelance

  121. pep.

    contact in? comms?

  122. MattJ


  123. pep.

    cool :)

  124. MattJ

    Someone I used to work who does marketing/comms is currently looking for more work

  125. pep.

    Do you think you can put me in contact? or maybe you're happy to handle it?

  126. MattJ

    It would be great if someone else were able, I'm a little overloaded right now

  127. MattJ

    But I can definitely put you in contact

  128. pep.


  129. ralphm


  130. ralphm

    pep., and I agree that we should figure that out, but unsure how to start, and if us being incorporated in Delaware affects how this works.

  131. MattJ

    I don't see why, I've done plenty of contracting for Delaware companies

  132. Guus

    maybe talk to Peter?

  133. pep.

    ralphm, I wasn't planning to talk about it until next week, but I've been poking SPI (https://spi-inc.org) and I see ways we could benefit from it

  134. Guus

    didn't the XSF hire laywers before?

  135. Guus

    should be a comparable process to hiring someone else.

  136. pep.


  137. Guus

    (I'm referring to Peter as I think he initiated that, back then)

  138. ralphm

    Guus: I asked Peter a while ago, but we haven't before.

  139. Guus

    ah, ok.

  140. ralphm

    I think the lawyers either worked for Jabber, Inc. or were kind enough to consult without a formal relationship.

  141. Guus


  142. ralphm

    But that doesn't mean that Peter might not have some good direction.

  143. ralphm

    So good idea to ask him.

  144. pep.

    nobody re SPI?

  145. Guus

    setting up a relationship with SPI would be something worth considering - but it'd take figuring out what that entails.

  146. Seve

    > nobody re SPI? I'm just reading it, didn't know them before

  147. ralphm

    I can't open that website, it requires TLS <1.2

  148. Guus

    I currently don't have a clue what kind of responsibilities that adds to our plate, and what we'd get in return.

  149. ralphm

    (i.e. Firefox complains)

  150. Guus

    (we're 15 minutes over time)

  151. pep.

    ralphm, they propose services for projects incl. "Accepting donations and holding funds", "Holding substantial assets", "Holding intangible assets", "Signing Contracts", "Legal assistance", "Technical services"

  152. pep.

    ralphm, yeah it complains here as well.

  153. ralphm

    Ah, good to know.

  154. ralphm

    Guus: good point, let's continue next week.

  155. ralphm

    5. AOB

  156. pep.


  157. ralphm

    6. Date of Next

  158. ralphm


  159. ralphm

    7. Close

  160. ralphm

    Thanks all!

  161. ralphm bangs gavel

  162. pep.


  163. MattJ


  164. Seve

    Thank you guys

  165. Guus


  166. pep_


  167. jonas’


  168. pep.


  169. pep.

    Testing that @id thing

  170. pep.

    Thanks Guus for the minutes

  171. flow

    regarding mail addresses, voting and memberbot: there is potentially the option that we feed memberbot with the N voting URLs for our N members and then every member can draw an URL via memberbot

  172. flow

    and regarding members.json: in germany you have to delete member/client data after a member/client leaves the society/club/company. so having members.json under VCS without explicitly pruning is a data protection violation

  173. flow

    i would expect the same to be true for most of the EU

  174. jonas’ scratches head

  175. flow

    my suggestion would be to move members.json outside the git onto a special folder and consider pruning the git

  176. jonas’

    now I wonder if that applies to a thing incorporated in delaware

  177. jonas’

    question is, where would that folder be hosted?

  178. jonas’

    we don’t have non-revisioned storage which can be accessed by non-admins

  179. flow

    on our infrastrucutre?

  180. flow

    probably, but that shouldn't be an issue

  181. jonas’

    the wiki has revisions, all git has revisions. and I don’t know of any other systems where we could give individuals outside iteam +w

  182. jonas’

    it currently *is* an issue

  183. flow

    yes, currently

  184. pep.

    pruning that from git is gonna be fun

  185. jonas’

    which brings me back to the question: "where would that folder be hosted?"

  186. jonas’

    and "on our infrastructure" is not a satisfactory answer to t hat

  187. jonas’

    kitchen, for real now

  188. flow

    if I only knew why it isn't an satisfactory answer, then I would be glad to make it one

  189. pep.

    I guess because of "I don’t know of any other systems where we could give individuals outside iteam +w"

  190. pep.

    There could be an upload folder thingy created for the secretary to update

  191. flow

    is it impossible to get the xsf secretary an account?

  192. jonas’

    flow, then you still need to make the file available to the build process. and, no, I’m not happy with passing around even restricted shell accounts as long as we don’t even have a central user account management on the servers.

  193. jonas’

    flow, so, SSH is out of the question for now, and then the question is: what service would host that folder, who would maintain that service, and how would we handle access control for people with +w to that folder as well as the build process which needs +r

  194. jonas’

    sorry, much of this was obvious from my perspective, but I can see how it might not be for everyone

  195. flow

    as much as I really like a central user management, i think I wouldn't block on that

  196. flow

    and i do not see an issue giving the xsf secretary an account allowing ssh

  197. pep.

    What about.. storing encrypted members.json in git instead :x

  198. flow

    same issue wrt build process i'd guess

  199. pep.

    hmm not so much different indeed.

  200. flow

    xep50 § 3.5.1 "Responders SHOULD consider any <x type='cancel'/> to be <x type='submit'/>." what does is that supposed to mean? I appears that xep50 does not use form type 'cancel' anywhere (at least i could not find it)