XSF Discussion - 2020-01-16


  1. moparisthebest

    thanks ralphm https://mail.jabber.org/mailman/private/members.mbox/members.mbox worked

  2. moparisthebest

    the term "Open Standard" is only mentioned once in XEP-0001, and never defined, does anyone know if the definition the XSF uses is actually defined anywhere? is it the same one the IEEE/IETF/W3C etc use? https://open-stand.org/about-us/principles/ ?

  3. nyco

    https://en.wikipedia.org/wiki/Open_standard

  4. nyco

    there is a lot of different definitions

  5. ralphm

    Indeed. Interesting table. I'll have a look later today to see where we currently would be exactly.

  6. pep.

    if we currently don't have an official definition I guess that's something members should have a say about (through board or not, there should be a thread for that at least)

  7. Guus

    ralphm with the excitement going on in the last few weeks, it might be good to, beforehand, have a clear expectation on what we will discuss (and possibly vote on) in todays board meeting. The Trello board only references the PR that was made by moparisthebest - I feel that that doesn't cover nearly all related things that we could discuss. To avoid having the meeting going off the rails, maybe it'd be good to have a specific agenda. By preparing one, we can prepare for the meeting too.

  8. pep.

    Agreed

  9. Guus

    In the back of my mind is that we could use the upcoming summit to discuss this with a broader audience, if we feel that we could use feedback from a larger group of people than the select few that have been speaking up online.

  10. Guus

    (which might reduce the load on todays agenda)

  11. pep.

    I wouldn't describe "online" as "select"

  12. pep.

    I'd rather qualify Summit as "select"

  13. Ge0rG

    But you can webex in!

  14. Guus

    What I ment to express: I've only seen a handful of people give their feedback online. Putting this on the agenda for the summit would allow us to explicitly invite even more people to discuss it. That only adds to the discussion that has also been going on online.

  15. pep.

    I get what you mean, but I think it adds to the discussion only for those who will be able to attend

  16. Guus

    Yes, obviously.

  17. pep.

    Thus I'd lean towards not limiting this discussions for summit

  18. pep.

    It will inevitably be discussed at summit, maybe not officially, but I'd encourage people to express their opinion on the list

  19. Guus

    I never implied limiting the discussion. Quite the opposite: I was wondering if we should put off deciding on anything until after we also addressed it at the summit.

  20. pep.

    fwiw I'm less comfortable discussing things like that in real time (online or offline)

  21. Guus

    You personally, or us as a group?

  22. pep.

    me

  23. Guus

    That's fine, of course. The opposite might be true for others though.

  24. pep.

    Well we're doing real-time just here :p

  25. Guus

    Also, I'm not saying we _need_ to postpone decisions. I'm just offering it something we could consider.

  26. pep.

    I agree we might want to spend a bit more time on this one tbh

  27. pep.

    As we've seen developping on the list, it's not that obvious, and our process probably needs clarification in any case

  28. jonas’

    Guus, I agree with pep. that summit is more select than the members list

  29. pep.

    fwiw that's what I'm been trying to do in sprints in the past. We've been criticised enough that sprints were quite opaque and decisions were made with no context. I've been trying to move away from that since then. (it's never easy). Of course people talk when they meet and that's fine, but I encourage them to also post to regular channels to allow others to contribute as well

  30. Alex

    the XSF newsletter always end up in my SPAM folder. Is it only me? Otherwise we should investigate why it ends up there

  31. Guus

    Alex: the newsletter arrived in my regular inbox. No oddities there for me.

  32. Alex

    Ok, will blame office365 then where I host my email

  33. eevvoor

    Alex isn't that from Moicrosoft?

  34. j.r

    > Alex: the newsletter arrived in my regular inbox. No oddities there for me. Same for me

  35. eevvoor

    Alex isn't that from Microsoft?

  36. Alex

    eevvoor: yes M$, Google already owns too much of my data, this is why I switched a while ago. Still wanna get away from MS as well soon

  37. eevvoor

    Alex I am relieved to hear that. mailbox.org or similar are worth their money: XSF newsletter goes to inbox :D.

  38. Alex

    eevvoor: yes, already have an account there,and it's my plan to move everything there

  39. eevvoor

    Alex emus opened a lot of tickets for their XMPP-Server. You can support those tickets. I stopped using the jid from their due to problems with tor.

  40. eevvoor

    Alex emus opened a lot of tickets for their XMPP-Server. You can support those tickets. I stopped using the jid from their due to problems with tor on android.

  41. Alex

    XMPP I will still self host. Its only for email and maybe calender

  42. jonas’

    what iOS client to use if you don’t need OMEMO?

  43. jonas’

    (but MUC and reliable message delivery)

  44. flow

    jonas’, android

  45. flow

    SCNR ;)

  46. jonas’

    yeah...

  47. jonas’

    that’s what I told them ;)

  48. MattJ

    jonas’, Monal or Siskin

  49. jonas’

    thanks

  50. jonas’

    what’s the difference?

  51. MattJ

    Stay well away from ChatSecure in my experience (limited personal experience from years ago, the rest is based on what I've heard from others)

  52. MattJ

    I've never used either in earnest, I've spent about 20 minutes playing with each... I don't know really, they're different

  53. Seve

    It is funny, ChatSecure is the only solution we found for an iOS user friend

  54. pep.

    Siskin doesn't do push notifications from what I understand?

  55. MattJ

    Both are a bit buggy

  56. MattJ

    pep., I saw something to the contrary about recently (today?)

  57. pep.

    cool

  58. MattJ

    https://mastodon.technology/@tigase/103488503676998610

  59. MattJ

    ("should improve #siskinim #xmpp #ios push notifications as well")

  60. jonas’

    MattJ, they’re amused by Monal marketing on the website at least :)

  61. jonas’

    > Privacy like it’s 1999 that’s objectively funny

  62. MattJ

    Heh

  63. jonas’

    MattJ, can Monal do MUC?

  64. MattJ

    Yes

  65. jonas’

    because it claims to be able to do OMEMO, and my impression was that on iOS, you have MUC <-> OMEMO: pick one.

  66. jonas’

    oh neat

  67. MattJ

    Don't use a '/' in your nick, but I expect most people wouldn't

  68. jonas’

    that scares me

  69. MattJ

    Yes

  70. jonas’

    a lot

  71. MattJ

    Indeed, now you begin to get the idea :)

  72. MattJ

    I found that bug right away, and I also had trouble with Siskin (it just hung while trying to join a MUC)

  73. MattJ

    I think that was without a '/', I'm not sure

  74. jonas’

    this smells like a bad JID parser

  75. MattJ

    Yes

  76. jonas’

    and I’m scared of those

  77. jonas’

    I should head home

  78. MattJ

    .split() probably

  79. jonas’

    split would be good

  80. jonas’

    seems like rsplit more likely

  81. MattJ

    It was matching and displaying only on the part before the /

  82. MattJ

    I joined as MattJ/foo and it thought I was MattJ, as far as I could tell

  83. MattJ

    I also found a few UI quirks that seemed a bit weird (that bug might have been the cause)

  84. MattJ

    When you join a MUC it doesn't open the chat log, it just added it to the 'chats' tab

  85. pep.

    !

  86. ralphm bangs gavel

  87. ralphm

    0. Welcome

  88. ralphm

    Who do we have?

  89. ralphm

    And any additional agenda items?

  90. MattJ

    Here

  91. MattJ

    No additional items

  92. Seve

    Hello!

  93. pep.

    Seve, hey

  94. pep.

    I assume Guus meant to be here with what he saod this morning

  95. ralphm

    Sorry Guus, I didn't see your message in time.

  96. Guus

    I'm here I'm here

  97. pep.

    s/soad/said/

  98. pep.

    fail sed even.

  99. ralphm

    But I'll try and keep it focussed.

  100. ralphm

    1. Minute taker

  101. nyco

    https://mensuel.framapad.org/p/9eh2-88prp5zhdc

  102. ralphm

    yay

  103. pep.

    nyco, thanks

  104. ralphm

    2. PR #876, removing objective 4

  105. ralphm

    I can be short on this.

  106. ralphm

    There is currently active discussion within the membership on this proposal. Interesting suggestions are being put out there, and I'd like to see where we end up with those.

  107. Guus

    I don't think that the PR does justice to the discussion, to be honest.

  108. pep.

    I'd like to keep the discussion going around this for some more time tbh

  109. ralphm

    Guus: it doesn't indeed. On face value I'd reject it.

  110. Guus

    The PR is about removing an objective completely, while the discussion goes much deeper into details on how that objective is to be interpreted.

  111. pep.

    Guus, the PR didn't just arrive for no reason, there some reasoning behind that (which you may or may not agree with).

  112. ralphm

    I can make an explicit comment in the PR that the members are discussing the change on content.

  113. Guus

    pep. I most certainly want to discuss the reasons for the PR - but I think we should explicitly list that as a goal

  114. pep.

    Guus, can you rephrase? not sure I understand the end of the sentence

  115. pep.

    A goal of what?

  116. ralphm

    As a matter of feedback to Travis, it would have been good if that context would have been made clear in the PR description.

  117. MattJ

    ralphm, I think that's sensible until discussion gives rise to an obvious next step

  118. pep.

    ralphm, agreed

  119. Guus

    I propose to explicitly define what we want (eventually) to decide on.

  120. MattJ

    As I said on list, I don't think context for the PR was needed necessarily

  121. eevvoor

    I am also here.

  122. MattJ

    I think separating out the licensing issues from deciding what our objectives are is a sensible move

  123. Guus

    "remove objective 4" isn't what is being discussed in the community, I feel. Mind, we should still act on exactly that, as that's what moparisthebest has asked for.

  124. MattJ

    which is why I think the discussion on the list has taken a better direction than the past weeks of fierce debates in this channel

  125. pep.

    Guus, to some extent it is. Maybe not in its entirety

  126. ralphm

    Guus: ok. We can do several things here: 1) reject the PR, 2) accept the PR, 3) request changes, 4) wait a bit for the broader discussion.

  127. Seve

    4) ?

  128. MattJ

    I would opt for (4)

  129. pep.

    I vote 4. I don't think I'm ready to reject nor accept it

  130. ralphm

    I'm suggesting 4 right now, and then either 3) or 1)

  131. Guus

    I'd opt to explicitly accept/reject the PR as is, but also to continue working on a more specific topic that reflects the motives behind the PR.

  132. Guus

    We've been asked "yes or no". We can't answer "blue".

  133. pep.

    I don't exactly know what removing objective 4 entails tbh. As part seems to be covered by IPR already

  134. ralphm

    Guus: a PR not black or white. Suggestions for changes is expected and common.

  135. Guus

    sure, but this is a very black and white question, that we could answer - while at the same time, continue to work on underlaying issues.

  136. Seve

    If we must reply yes or no, I would go for reject that PR and continue the discussion, but to me, leaving the PR open makes people remember we have something to discuss

  137. Seve

    So I prefer it open

  138. Guus

    I think that there's merit in keeping the discussions clean and on point. I feel that answering questions 1-or-1 is good for that.

  139. pep.

    I disagree that it's a yes or no question. You don't just accept or refuse a PR. You work with the author and give feedback (to either improve the PR to a clear goal, or to refine the goals and then work on that), and then only make a decision.

  140. Guus

    I think that there's merit in keeping the discussions clean and on point. I feel that answering questions 1-on-1 is good for that.

  141. Guus

    Not a hill for me to die on. I just fear we're muddying the water.

  142. pep.

    Now, goals are somewhat stated in https://mail.jabber.org/pipermail/members/2020-January/009076.html but what does that entails. We're going to have to maintain it afterwards

  143. pep.

    (What does the change entail*)

  144. Guus

    pep. I don't understand what you want to say.

  145. ralphm

    I can add the following: "Board has discussed this PR, and would reject it in its current form. However, Board is aware of the broader discussions on our IPR Policy, the definition of Open Standards, and potentially allowing specifications that violate Objective 4 and/or the IPR Policy. In that light we'd like to see rough consensus to emerge from those discussions, and then suggest changes to this PR, or close it in favor of another PR that reflects said rough consensus.

  146. pep.

    ralphm, I'm not saying I would reject the PR fwiw. That's where I'm leaning towards but I'd like to know what that means before.

  147. pep.

    **I'm leaning towards accepting it

  148. ralphm

    pep., obviously I would add that message after agreement here :-D

  149. ralphm

    pep., not knowing what it means would be a reason to reject, hopefully.

  150. pep.

    Well, I obviously have an idea

  151. MattJ

    I'm fine with the proposed comment

  152. Seve

    ralphm, sounds just perfect to me! very good work

  153. Guus

    That's good, but what I'm looking for is a definition on what we're actually seeking to have consensus for. Is it about the XSF having Objective 4? The definition of what is 'encumberance'? The definition of what is an 'open standard'? The future of Omemo? ...

  154. ralphm

    yes, yes, probably, no

  155. pep.

    I'd say yes for defining "open standard" :x

  156. Guus

    to have on-point discussions, it might be good to create a list of issues we want to specifically have addressed.

  157. ralphm

    Guus: to be honest, I don't feel that we have to manage the discussion.

  158. MattJ

    Same here

  159. pep.

    How so?

  160. MattJ

    I'd let it continue as it is

  161. MattJ

    and we can review at our next meeting

  162. Guus

    Okay, so when do we close the PR?

  163. Guus

    what's the milestone that we're waiting for then?

  164. pep.

    I'm also confused now

  165. MattJ

    How so? Was Ralph's proposed comment on the PR not clear enough?

  166. pep.

    MattJ, that's us "not managing the discussion"?

  167. pep.

    Who is going to make that other PR

  168. pep.

    Who decides when there is consensus

  169. MattJ

    pep., we don't know that there will be another PR

  170. MattJ

    We do

  171. MattJ

    Because it's up to us to make the decision

  172. pep.

    So what's the limit? Do we close the PR at some point because everybody forgot about it?

  173. MattJ

    What?

  174. ralphm

    There's no limit on accepting or rejecting this PR. XEP-0001, Section 10 reads: Procedural XEPs may be modified more frequently as the XMPP Standards Foundation gains experience with the processes defined therein. For example, XEP-0001 is modified periodically in order to document processes previously not made explicit or to modify existing processes based on experience with the XSF's standards process; similar changes are sometimes made to the XMPP Registrar Function (XEP-0053) [17] XEP and to various SIG-related XEPs. Changes to these XEPs are discussed by the XMPP Council, XSF Board of Directors, XSF membership, and Standards SIG as appropriate, and exact changes are agreed to by the relevant approving body (XMPP Council or XSF Board of Directors). The approving body then instructs the XMPP Extensions Editor to publish and announce the revised version as described above.

  175. pep.

    MattJ, if we don't lead the discussion I'm not sure how we'll manage to get consensus on all that, is what I mean

  176. Guus

    I think what pep. is saying is that it'd be good to define some kind of explicit goal, more specific than 'reach consensus on an undefined discussion'

  177. ralphm

    Guus: please suggest something then

  178. Guus

    Well, the four I just used as for-examples.

  179. Guus

    with some more thought and feedback, we can probably improve on those a little.

  180. MattJ

    I don't want to constrain the discussion, if we'd done that at the start we wouldn't have had some of the interesting solutions come up

  181. ralphm

    MattJ, agreed.

  182. MattJ

    i.e. "the PR is not black and white"

  183. Guus

    I'm not implying that it'll be a finite list.

  184. pep.

    I agree it's not black and white

  185. MattJ

    Then why make a list?

  186. ralphm

    Ok, let's make this concrete.

  187. Guus

    ah, forget it, as I said, not a hill to die on.

  188. MattJ

    There are ongoing discussions, we don't want to make a decision right now. I don't understand what's so difficult/bad about that stance.

  189. dwd is looking forward to an infinite list of discrete options.

  190. ralphm motions we lead the discussion on the topics around this PR, and provide a set of goals to the membership.

  191. ralphm

    -1

  192. pep.

    MattJ, to me an explicit goal would be for board to for exemple review discussions around that on a regular basis

  193. pep.

    ralphm, what?

  194. pep.

    Why a vote.

  195. MattJ

    Heh

  196. ralphm

    pep., I worded Guus' suggestion, and then voted against it.

  197. ralphm

    pep., to make it concrete. I see various people objecting above

  198. MattJ

    -1 as worded, I would like discussion to continue

  199. MattJ

    and as I said, we can review at our next meeting

  200. pep.

    Of course I also want the discussion to continue

  201. ralphm

    pep., sure, we already had consensus on the message I suggested to be added to the PR. I.e. just you objected. Then Guus seemed to want to amend it, and I saw broad disagreement.

  202. ralphm

    I like to move forward.

  203. MattJ

    It's past time, I need to move on. Is there anything else significant on the agenda for today?

  204. ralphm

    MattJ, nothing that can't wait, IMO

  205. Seve

    I would say let the discussion be and keep checking until we feel we can start defining something

  206. Guus

    Sorry, I got interrupted.

  207. Guus

    Reading...

  208. pep.

    ralphm, we haven't made a decision on the PR, so as concrete feedback I'd like to remove "and would reject it in its current form" from your message

  209. pep.

    I agree with the rest

  210. ralphm

    what if I'd use 'likely' in there?

  211. pep.

    ..

  212. MattJ

    Just scratch that part

  213. ralphm

    ok

  214. ralphm

    3. AOB

  215. MattJ

    I agree that we don't know whether we would reject it until we actually collectively make that decision

  216. ralphm

    No AOB

  217. MattJ

    None here

  218. Guus

    I'm -1 on on R's motion, for the record - that's not what I ment, but I"ll leave it rest.

  219. Guus

    no AOB

  220. pep.

    No AOB either

  221. ralphm

    4. Date of Next

  222. ralphm

    +1W

  223. MattJ

    wfm

  224. ralphm

    5. Close

  225. ralphm

    Thanks all!

  226. ralphm bangs gavel

  227. pep.

    Thanks

  228. nyco

    please review, edit : https://mensuel.framapad.org/p/9eh2-88prp5zhdc

  229. Seve

    Thank you very much nyco

  230. Guus

    lgtm nyco

  231. pep.

    ralphm, are you going to post that then to the PR?

  232. ralphm

    Did

  233. pep.

    Thanks

  234. jonas’

    ralphm, is it okay if I edit your comment to add references to it? specifically, I’d like to link the members thread and the board meetings chat log

  235. jonas’

    (I do have the power to do so, just asking out of curtesy)

  236. ralphm

    No, but you can add a comment

  237. jonas’

    people tend to ask for rationales about decisions recorded in the PRs, and I like to have them linked for future reference

  238. jonas’

    okay

  239. moparisthebest

    yep, I went to add a link to the mailing list when I first created it but couldn't edit

  240. ralphm

    jonas’: indeed. Thanks

  241. jonas’

    done

  242. pep.

    thanks

  243. moparisthebest

    it's probably not very "open" for an organization to block comments

  244. pep.

    moparisthebest, it's not about blocking comments, it's about limiting discussion venues :/

  245. moparisthebest

    right, as long as there is a link to said discussion :)

  246. jonas’

    moparisthebest, moving discussion from a proprietary platform to an openly joinable XMPP MUC is the intent of that (which I also wrote) and why I do that

  247. jonas’

    there is

  248. jonas’

    the link to the XSF muc directly points to a Converse.js instance

  249. jonas’

    the link to members points to the mailing list, but is obviously accessible only to members (for writing, that is)

  250. jonas’

    (but since a github account is not a pre-requisite for being an XSF member and this is something to be discussed by members, members@ is the better venue compared to the PR)

  251. moparisthebest

    yep that's perfect, I totally agree on that

  252. jonas’

    so I don’t see an issue with locking the PR -- as long as the reason is documented

  253. jonas’

    so I don’t see an issue with locking the PR -- as long as the reason is documented and the alternative venues are clear

  254. jonas’

    (also, I don’t pro-actively lock PRs, I only lock them when non-editoral discussion starts)

  255. jonas’

    I wish there was a way to give a custom reason for locking

  256. jonas’

    with a URL or something

  257. Guus

    It is good to not fragment the discussion over multiple venues, if only for reference in the future.

  258. jonas’

    but that’s not an option

  259. jonas’

    I like that we all agree on this, thanks

  260. jonas’

    refreshing

  261. Guus

    Let's move it all to github. /me ducks, runs.

  262. moparisthebest

    if the XSF hosted their own git*** instance I'd be ok with that but yea, another day maybe... :)

  263. Guus

    haha, no, I'm not even suggesting github in earnest. MUC and mailinglist are good, for me.

  264. moparisthebest

    mailing list still needs fixed, no response in iteam, but otherwise yes

  265. Guus

    improvements to the infrastructure would be nice.

  266. jonas’

    I’d like to note for the record that I lost privileges on the xmpp.org repository.

  267. jonas’

    Just in case that was by accident.

  268. jonas’

    (because I wasn’t notified)

  269. jonas’

    If it was intentional, a notice would’ve been nice and also a reason (though "you are not part of any team which should have access" is a perfectly valid reason to me)

  270. Zash

    The web repo?

  271. jonas’

    yes

  272. Zash

    MattJ did a sweep of gh permissions iirc

  273. jonas’

    that makes sense

  274. jonas’

    If it’s intentional, I’m also going to unwatch that repository, which will reduce the load on my inbox \o/

  275. MattJ

    It was discussed here multiple times and documented in Board minutes I hope

  276. jonas’

    must’ve missed all of it then

  277. MattJ

    I made a bunch of changes, and notified people I thought needed notifying

  278. jonas’

    though neither github nor permissions as search terms finds any matching board minutes

  279. jonas’

    either way, I’m then going to unwatch, no problem

  280. MattJ

    For the record, here is what I wrote (here) when I did it:

  281. MattJ

    20191203T11:03:51Z <MattJ>  Speaking of iteam, I'm updating Github permissions as we discussed in one of the recent board meetings 20191203T11:04:28Z <MattJ>  Anyone who doesn't have access to something they think they ought to have access to, feel free to poke me and I'll investigate 20191203T11:05:21Z <Zash>  Who should have access to what? 20191203T11:07:29Z <MattJ>  The main change is that there is a (hidden, iirc) "Web" team 20191203T11:07:38Z <MattJ>  which has a bunch of people in it 20191203T11:08:09Z <MattJ>  All the people who are actually doing stuff are already in teams that already have access to the relevant repos 20191203T11:08:37Z <MattJ>  So the goal is to simplify Github permissions so they align with XSF team membership 20191203T11:09:01Z <MattJ>  which will make it easier to see and manage who has access to what 20191203T11:11:28Z <MattJ>  to clarify what I wrote above - the "Web" team exists, but is being removed in favour of more well-defined teams

  282. jonas’

    oh, that’s quite a bit back

  283. jonas’

    thanks, I would’ve thought it was a newer thing

  284. jonas’

    thanks, I would’ve thought it was a more recent thing

  285. MattJ

    I haven't made any changes since then

  286. jonas’

    I remotely recall observing this, actually

  287. jonas’

    and simply forgot about it

  288. jonas’

    but I think that was also the day I got massively sick in dec, so that’s probably why I completely eradicated it from my brain

  289. Guus

    Maybe it is good to verify that the access that you no longer have can be explained by iteam's cleanup - if only to rule out another cause?

  290. Guus

    jonas’ being an editor and on council would imply access to a lot, I'd think?

  291. jonas’

    Guus, it does make sense though. I’m not part of any team except Editors, and that is correctly reflected in the xsf github org

  292. Guus

    ok!

  293. jonas’

    I don’t think Council has a team on our github org (board has tho)

  294. Zash

    Should Council have one and why?

  295. jonas’

    I don’t think it should

  296. jonas’

    there isn’t anything in there managed directly by council

  297. jonas’

    council has the editor as its minion

  298. Zash

    This is fine.

  299. Guus

    editors having access to xmpp.org would not make me unhappy, fwiw

  300. jonas’

    Zash, whenever somebody says "This is fine.", I have that meme picture with the dog and the burning house in my mind

  301. jonas’

    thanks, internet.

  302. Guus

    (same here)

  303. Zash

    jonas’, not entirely unintentional :)

  304. dwd

    https://www.thetoychronicle.com/product/lil-dumpster-fire-by-100soft/

  305. Zash

    Tho I don't mean it like that

  306. Guus

    didn't I read somewhere that that toy was modeled after an image without its authors permission?

  307. dwd

    FWIW, I would be perfectly hapy for any of the people currently on the XMPP Editor team to have access to the website, but I wouldn't like to make any implication that XMPP Editors should automatically have do anything to the website.

  308. Guus

    </brainfart>

  309. Guus

    dwd then we should not have them at all. Let's keep things clean.

  310. dwd

    I mean, if anyone in the Editors team *wants* to be on the web team that's awesome.

  311. Zash

    Wasn't there a different team responsible for the website?

  312. Guus

    wfm

  313. jonas’

    if there is a team which is responsible mainly for xmpp.org, I’m happy to officially join it

  314. jonas’

    not with the intent of upping my workload, but with the intent of keeping doing what I’ve been doing on xmpp.org in the past

  315. Zash

    commteam?

  316. jonas’

    (approving stuff and hitting merge)

  317. pep.

    Wasn't the "web team" removed? Or going to be? As there's no equivalent XSF Team

  318. jonas’

    ^

  319. jonas’

    I guess it’s commteam

  320. pep.

    Right, something like that was agreed I guess

  321. jonas’

    that’s how I lost access I suppose :)

  322. jonas’

    I start to recall all of it. that sick time must’ve [pn]uked quite a bit of my brain

  323. Daniel

    I’m wondering if the "who are we and what are we doing" debate that we are currently having is long overdue or just stopping us from getting actual work done

  324. dwd

    Daniel, It can be both.

  325. Kev

    I think that it's stopping other work happening is a given.

  326. MattJ

    Definitely both

  327. Kev

    The question is on part one :)

  328. Kev

    I don't really have the cycles to reply to the LC right now - but I note that one of my comments from last time has been overlooked (I think Daniel genuinely intended to address it), which is that revealing IPs should probably be in the security considerations.

  329. Daniel

    Kev, i’ll make a note. i’m going to address the 'requirments' things that came up anyway so i can just do both

  330. Kev

    Ta.

  331. moparisthebest

    well it's at least clear that we don't have important terms like "open standard" defined, and that each member's definition can vary wildly, so it's a needed discussion regardless

  332. moparisthebest

    if we don't want a discussion then that objective can be deleted and we can move on, otherwise it's hard discussions/decisions

  333. dwd

    I don't think deleting the objective should be any kind of default.

  334. moparisthebest

    well that's the easy option if we don't want to have this discussion

  335. dwd

    It really isn't.

  336. moparisthebest

    the hard option is probably better, but it's harder

  337. dwd

    It's just the action you want, which is very different.

  338. moparisthebest

    that's not even true, I just want something to come out of this that represents what the members want the organization to be, it seems to be going in that direction so that's great

  339. !XSF_Martin

    q

  340. dwd

    It is totally true. You've bent and twisted everything you can in order to get your own way, and refused to even consider compromise beyond a way to leverage further concession.

  341. dwd

    I'm really quite angry at the way you're acting, and this suggestion that we should utterly change the organisation purely because it suits you is absolutely typical.

  342. pep.

    > Daniel> I’m wondering if the "who are we and what are we doing" debate that we are currently having is long overdue or just stopping us from getting actual work done That's generally the first thing one is supposed to do if they want to see something succeed (otherwise nobody is aligned, meh results, lots of efforts wasted on all sides)

  343. moparisthebest

    I don't think so? I completely agreed with your proposal even, as long as there was a way to move between them right?

  344. moparisthebest

    dwd, you have an idea about what this organization does in your head, and that's the only place it exists, it's not written down or defined, I'm just asking for that to happen, the version I have in my head is quite different

  345. moparisthebest

    and this seems like a productive discussion to accomplish that, no one should be angry about it?

  346. pep.

    > dwd> I'm really quite angry at the way you're acting, and this suggestion that we should utterly change the organisation purely because it suits you is absolutely typical. wat.

  347. moparisthebest

    it's certainly not my intent in any way to make anyone angry, we are all on the same team here

  348. Kev

    At least the impression I've got isn't that you've asked to have what we current do documented, but to change what we currently do.

  349. moparisthebest

    I don't know what we currently do because it's not documented, so I don't even know if it needs changed

  350. moparisthebest

    basically I expressed concern with a certain unwritten rule, I was told to put in a PR and start a discussion, what exactly is wrong with that?

  351. dwd

    moparisthebest, By removing a written rule you wanted changing.

  352. Kev

    And radically change, even, removing the objective to produce what I understand to be an open standard would undermine what some people, like Dave, have put huge amounts of time into helping build over the last over a decade, including 'selling' it to various parties precisely because of that objective.

  353. moparisthebest

    "what I understand to be an open standard" < that's the problem Kev

  354. moparisthebest

    you and I have a different understanding, and it's defined nowhere

  355. moparisthebest

    as I said, wikipedia lists 22 different definitions

  356. Kev

    Yes, we have institutional knowledge enshrined in what we do, and it is difficult for a newcomer to assess that. I'm fine with accepting that.

  357. Kev

    Assess and/or access.

  358. moparisthebest

    so I put in a PR, got a discussion going, and I thought it was going very well, dwd 's proposal seemed great to me

  359. Kev

    And documenting those things seems like a Very Good Thing (although limited volunteer effort, etc.).

  360. Kev

    But documenting those things doesn't start with radically changing those things that we do have formally specified.

  361. moparisthebest

    ralphm told me to start the official discussion with a PR

  362. moparisthebest

    if that was wrong, I'm sorry

  363. Kev

    I think Ralph said (from memory) that if you wanted to change our policy, the way to do it was with a PR. And that's correct.

  364. moparisthebest

    no one should have taken a PR as an insult, please don't do that

  365. moparisthebest

    are PR's supposed to only be perfect and never discussed? because I didn't expect that to be the case at all, at least with this one

  366. moparisthebest

    it seems most people agree with me that that particular objective needs work

  367. Kev

    No, I don't think anyone involved with dev in any aspect expects PRs to be perfect every time.

  368. dwd

    "needs work" != "removed entirely".

  369. dwd

    As you surely know.

  370. moparisthebest

    right, and this got that discussion going

  371. Kev

    It depends if you mean 'work' in the sense of 'better document where we are' (which I don't see most people agreeing) or 'completely remove', which is what you proposed.

  372. moparisthebest

    I also didn't know exactly what changes were needed to fix it, doesn't seem like anyone is clear on that yet

  373. Kev

    I don't see that anything needs 'fixing' here, beyond better documenting our institutional knowledge.

  374. moparisthebest

    well, documenting is one, but looks like a substantial portion also wants a way to move forward with things that may or may not fit whatever "open standard" definition we go with

  375. Kev

    That is your assessment. I'm mostly seeing a small number of people making (considerable) noise about changing it, but not a large number of people.

  376. moparisthebest

    bottom line I didn't mean this PR as an attack on the XSF or anything, and if it came off like that I apologize

  377. moparisthebest

    I think the discussion was needed and is good, and should continue on it's current course, that's all

  378. Kev

    FWIW, I think if we progressed with the suggestion made not very long ago to formalise the inbox to be a little like the IETF's individual submissions (the stuff that's not adopted by a working group), such that it is published and has an id, but not an RFC number, and that Council wouldn't need to make any judgement calls on such things, they just get published mechanically and Council only needs involvement if something wants to move from that to a XEP, would be a similar approach to what Dave proposes, but having additional benefits of solving other issues we've had with the process over the years.

  379. Kev

    e.g. when I've submitted XEPs that were large numbers of TODOs because we needed it under XSF IPR to start discussing it sensibly at a Summit.

  380. ralphm

    By the way, I thought about this a bit more on the way home. While indeed the XSF currently does not have on-staff legal support, we *did* have our IPR Policy vetted (see the Acknowledgements section). It is my opinion that section 3.2 exactly states what the XSF believes to constitute an open standard and what it believes to be an encumbered protocol. I think this is more than good enough.

  381. ralphm

    I'd be happy to expand on this, but now I want to go drumming.

  382. Kev

    As any decent human would.

  383. moparisthebest

    4.2 ? 3.2 is https://xmpp.org/extensions/xep-0001.html#types-Informational but no rush, whenever you get around to it ralphm

  384. ralphm

    moparisthebest, section 3.2 of our IPR

  385. ralphm

    Policy

  386. ralphm

    https://xmpp.org/about/xsf/ipr-policy#contrib-approval

  387. moparisthebest

    thanks!

  388. ralphm

    (and whenever the website is regenerated, it will actually say 3.2 instead of 3.3.

  389. ralphm

    )

  390. moparisthebest

    so that significantly differ's from IETF's definition of an open standard, which explicitly does not require royalty-free for example, interesting ( ietf's https://open-stand.org/about-us/principles/ )

  391. moparisthebest

    that says it must be able to be implemented under fair terms, and says "Given market diversity, fair terms may vary from royalty-free to fair, reasonable, and non-discriminatory terms (FRAND)."

  392. moparisthebest

    I couldn't immediatly find a definition for FRAND

  393. ralphm

    Well, yes, FRAND is murky

  394. ralphm

    https://en.m.wikipedia.org/wiki/Reasonable_and_non-discriminatory_licensing

  395. ralphm

    moparisthebest: just for my understanding, is this your first read of our IPR Policy?

  396. moparisthebest

    and that seems to be entirely about patents, and nothing about copyright

  397. moparisthebest

    this is all awful

  398. dwd

    moparisthebest, Nobody considers software licensing in standards, because no specification can exist if it's only in software.

  399. moparisthebest

    I'm sure I read it at least when I assigned IP to the XSF

  400. ralphm

    And this is why many of us are upset about OMEMO and its relation to libsignal. I strongly believe copyright on a protocol itself to be a problem. (I'm not talking about a spec or an implementation)

  401. ralphm

    moparisthebest: that explains. This is also why people get upset.

  402. moparisthebest

    it's still not nearly clear enough on the XSF's side, as someone stated in that email thread, that section is about Approval, Experimental are not approved etc etc

  403. ralphm

    moparisthebest: while that might be true, we *do* have a clear idea about what we believe unencumbered means.

  404. moparisthebest

    ralphm, *you* do, mostly no one else does though

  405. jonas’

    I do, too

  406. jonas’

    (I think)

  407. ralphm

    Also, I mentioned the IPR Policy many times in many posts, mails, and I'm surprised you haven't read it (again) up till now.

  408. jonas’

    since everything what ralphm said about it so far made sense to me

  409. moparisthebest

    as I stated before, GPL is not an encumbrance in my book

  410. ralphm

    moparisthebest: but it is in the XSF's

  411. moparisthebest

    dwd and ralphm also have very incorrect ideas about how the GPL somehow prevents anyone from making money in business or something, I've avoided responding to them on list because it's too off topic

  412. moparisthebest

    ralphm, the XSF doesn't have a written definition

  413. dwd

    moparisthebest, Not to you, perhaps. But it clearly is to someone who wishes to license any other way; I think that the GPL would be blocked by FRAND (if that were ever applied to licensing) as it constitutes a grant-back, which hasn't passed FRAND.

  414. moparisthebest

    that's in fact my entire problem with this, if it's not written down it doesn't exist

  415. dwd

    moparisthebest, Also, stop telling me what I think.

  416. moparisthebest

    that seems to be going both ways lately doesn't it? :)

  417. dwd

    moparisthebest, I know perfectly well that the GPL allows commercial activities, but the fact remains that is also mandates the GPL.

  418. moparisthebest

    the reason I think dwd 's proposal is great is that kind of thing can just, go away. in the omemo case say moxie publically documents the constants, or someone contacts them and they say it's fine

  419. moparisthebest

    I tried to find a good definition for "encumbrance" yesterday actually, and almost all only use it in reference to real estate, like someone having a lien or mortgage is an encumbrance

  420. moparisthebest

    if "open standard" and "encumbrance" were clearly defined, no one would even be having this discussion, the fact that we are means it is not, and that needs fixed

  421. jonas’

    striving for full definition of everything is what brings us massive lawbooks nobody has time or energy to read anymore.

  422. dwd

    "Any burden, interest, right or claim which adversely affects the use of, or the ability to transfer, property."

  423. dwd

    That's (a) legal definition, the first one that came up on Google.

  424. moparisthebest

    yes, that one is about real estate

  425. moparisthebest

    "property" there

  426. jonas’

    can’t it be intellectual property

  427. dwd

    That's not what "property" means. It includes real estate, certainly, but also software or anything else that can be owned independently.

  428. ralphm

    moparisthebest: I believe your above statement is a gross misrepresentation of my nuanced stance on these topics. I will expand later, but much of what Dave says.

  429. ralphm

    And also all the stuff I've written before on this the last two weeks.

  430. Kev

    When you read your mail to standards@ back, and spot that many typos, it's definitely time to be going to bed and not writing emails.

  431. ralphm

    Hehe

  432. Guus

    Instead, you turned to this muc. What could possibly go wrong.

  433. pep.

    > ralphm> (and whenever the website is regenerated, it will actually say 3.2 instead of 3.3. > ) it should already?