XSF Discussion - 2020-04-30

  1. pep. !
  2. pep. Guus, MattJ, ralphm, Seve
  3. Seve Hello
  4. ralphm bangs gavel
  5. ralphm 0. Welcome + Agenda
  6. ralphm Hi, who do we have?
  7. MattJ o/
  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. thanks
  15. Guus No additional agenda items for me
  16. ralphm 2. Member opinion
  17. ralphm pep.?
  18. pep. yep
  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. Sure
  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 exactly.
  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. yes
  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 Indeed
  72. pep. Ah I have an AOB from Flow regarding members.json (just remembered)
  73. ralphm pep., different from this?
  74. pep. yes
  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. yeah
  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. nope
  87. ralphm https://wiki.xmpp.org/web/GDPR/Privacy_Policy_Template
  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 Right
  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 Ok.
  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 tx
  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 ok
  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 same
  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 Yeah
  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. thanks
  129. ralphm Cool.
  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. https://spi-inc.org/projects/services/
  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 k
  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. none
  157. ralphm 6. Date of Next
  158. ralphm +1W
  159. ralphm 7. Close
  160. ralphm Thanks all!
  161. ralphm bangs gavel
  162. pep. Thanks
  163. MattJ Thanks
  164. Seve Thank you guys
  165. Guus Thanks
  166. pep_ .
  167. jonas’ duplipep
  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)