XSF Discussion - 2017-09-26


  1. moparisthebest

    I think the reason good ux goes against security is because those are generally different developers

  2. moparisthebest

    Especially for web

  3. emxp

    moparisthebest: i just remember how Constanze Kurz from CCC said something like: 'we need to bring students from other disciplines in contact with IT - even so art students'

  4. jonasw

    FLOSS needs more designers indeed

  5. mimi89999

    đź‘Ť

  6. emxp

    and as a tech student say so too. why am i 'locked' into a pure technological based university? so we need the other way round too

  7. edhelas

    yup I agree

  8. zinid

    art can be learnt actually (especially graphics design, where you basically only need to pick right colors and shapes), but nobody wants to do this

  9. jonasw

    I doubt that "nobody" wants to do this, there are quite a few graphic designers out there.

  10. zinid

    jonasw: ok, I mean a typical developer

  11. jonasw

    I just think it’s pointless to force yourself to do something you don’t like if you could be doing something you *do* like (and possibly even are already good at).

  12. jonasw

    better get an interested graphics designer involved

  13. zinid

    how?

  14. zinid

    how will s/he join xmpp?

  15. zinid

    via photoshop?

  16. jonasw

    zinid, they don’t need to join XMPP to contribute.

  17. jonasw

    (whatever joining XMPP means)

  18. zinid

    can you please describe the working flow of such designer?

  19. jonasw

    I have no idea of designer workflows?

  20. zinid

    I have :) I hired some back in the time

  21. jonasw

    then you can shed some light on it :)

  22. zinid

    what I meant is that there should be incentive for a designer: money or interest

  23. zinid

    since s/he's not joined XMPP (not interested) only money left

  24. Zash

    Everyone have their motivation sources

  25. jonasw

    zinid, I don’t think that "isn’t part of XMPP" (still, whatever that means) implies "not interested" for sure

  26. zinid

    in 15+ years of xmpp development I can barely remember as single designer

  27. jonasw

    it can also imply "doesn’t know the key point which leads to interest yet" or "doesn’t know about XMPP at all yet

  28. jonasw

    it can also imply "doesn’t know the key point which leads to interest yet" or "doesn’t know about XMPP at all yet"

  29. uc

    #Opensourcedesign on Freenet

  30. zinid

    *a

  31. jonasw

    zinid, that’s maybe because most of XMPP development takes place in the FLOSS community, where there are generally only few designers abound

  32. jonasw

    (and what doesn’t take place in FLOSS often doesn’t announce XMPP that loudly)

  33. uc

    Freenode**

  34. Zash

    Have there been any studies on the general lack of designers in FLOSS?

  35. jonasw

    Zash, either there is a general lack, or they are mostly horrible ;-)

  36. Zash

    90% of everything is horrible

  37. emxp

    jonasw, zinid: I think in first hand it is important for devs and designers to get an understand of each focuses and how they think. thus the designer and devs can adapt their work or workflows to bring them together. that why I said combine the studies or at least let them get in contact. i think both sides are interested in each other. but there is no need for each side to do others work if they dont want to. so just get an understanding. what makes good UX, what makes good security? (e.g less is probably more!) and so on. there are lots of (mainly) non tech people in the CCC for example

  38. jonasw

    +1 emxp

  39. Zash

    eh

  40. Ge0rG

    So we need to acquire some designers...

  41. emxp

    actually, whats the puropose of XSF? Do you collect money, too? For example, to pay people for specific programming/design tasks?

  42. SouL

    I would say XSF cares about XMPP, the protocol.

  43. SouL

    Software is a thing for developers.

  44. zinid

    probably collecting money and hire designers is not that bad idea

  45. emxp

    SouL: maybe there should be an extended foundation or so. in principle like Google Summer of Code. but only for xmpp purposes

  46. emxp

    i would donate money

  47. emxp

    This foundation furthermore could spend money on other things which supports xmpp too

  48. zinid

    emxp: I think XSF has donations already

  49. Guus

    exmp: The XMPP Standards Foundation (also known as the XSF and formerly the Jabber Software Foundation) is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messaging and Presence Protocol (XMPP).

  50. Guus

    copy/pasted that :)

  51. Guus

    as for sponsorship - that's obviously very welcome. There's a sponsorship programme defined here: https://xmpp.org/community/sponsorship.html On top of that, we occasionally ask for sponsorship regarding individual events (mostly the XSF Summits)

  52. zinid

    I think what we really need is more full-time developers, 95% of xmpp projects are maintained in spare time, most of the projects can barely survive 10-year period (I can count only a few)

  53. Guus

    arguably a very good way to support the XSF, besides donating money, is to be actively involved in the activities that we undertake. There's a lot of things that we do, from defining protocols, to providing internal support (to our website, this chat, preparing for conferences, etc)

  54. zinid

    Guus: donating to XSF will not help xmpp in my opinion

  55. Guus

    zinid: I don't think that's something that should be initiated by the XSF. The XSF is there to develop the protocol, not the implementations.

  56. zinid

    Guus: I don't say XSF should do that

  57. Guus

    Well, there are plenty of open source, but also commercial organisations, that do development on XMPP

  58. Guus

    I'm sure that many of these will gladly accept help

  59. Guus

    By the way: most of the servers listed on our website are older than 10 years. There definately is a solid foundation there.

  60. MattJ

    Prosody is 9

  61. zinid

    I almost always talk about clients when I say "xmpp software" :)

  62. MattJ

    Client software is harder - platforms and UIs change

  63. zinid

    no surprise we have some servers with commercial support, because it's easier to build bussiness model with them

  64. MattJ

    All the 10-year clients around, people now call them ugly

  65. zinid

    MattJ: exactly

  66. Guus

    zinid: so, open up an IDE and start typing :)

  67. Zash

    Wrong shade of grey

  68. Guus

    there's a good deal of libraries available that you can (re)use to create new stuff

  69. Guus

    but you're absolutely right - we could really use more nice clients.

  70. zinid

    Guus: I cannot do everything myself, obviously, I'm a server dev

  71. Ge0rG

    I think that the XSF urgently needs to widen its scope from "protocol" to "software", so it can provide UX guidelines etc.

  72. Zash

    back to*

  73. Ge0rG

    yaxim is only eight years so.

  74. Ge0rG

    yaxim is only eight years old :(

  75. Guus

    I'm not sure if I agree, Ge0rG.

  76. Zash

    Recreate the Jabber Software Foundation as a separate entity

  77. Ge0rG

    Zash: I've been pondering about that.

  78. Guus

    On first thought, I'd prefer that. Will have to give it more thought though.

  79. Ge0rG

    Zash: but the main issue I see is: it will be run by a subset of the same people as the XSF, and those are already short on time.

  80. emxp

    Guus, zinid, Ge0rG: Yes, its good that XSF is focusing on the protocol. so my suggestion was to focus with another on implementations and full time payments

  81. emxp

    for devs

  82. emxp

    or part-time in the beginning

  83. Zash

    Where'd the money come from?

  84. Ge0rG

    Besides, I'm convinced that "protocol" also includes defining certain user-facing elements. Like how to call entity addresses for that protocol.

  85. Guus

    emxp: again, I'm not arguing that it's a bad idea. I don't think you'd need a separate organization for that though, as existing ones will be very happy to accept your help.

  86. zinid

    emxp: there is an initiative to collect money for Jingle support in conversations, it ended up with 500$ or so ;)

  87. Ge0rG

    emxp: you need a dozen developers and a year of time to make a well-polished XMPP client. So if you have a million dollars, let me know.

  88. zinid

    nobody wants to donate

  89. Zash

    Sure there are people who want to donate, but you aren't going to get full time developer pay from donations

  90. zinid

    take a look at Matrix, they have funding problems and started fundrasing, the result is 2800$ : https://www.patreon.com/matrixdotorg

  91. zinid

    and Matrix is quite hyped at the moment

  92. Guus

    zinid: arguably, they _now_ have funding problems, because they started off as a fully funded project (which suddenly lost its sole sponsor).

  93. zinid

    and Matrix has 11 developers, lol :)

  94. Zash

    -do 2800 / 11

  95. Bunneh

    Zash: 254.54545454545

  96. zinid

    what a bunch of money!

  97. Guus

    zinid, what do you propose?

  98. daniel

    for their london office this pays for the oyster card they need to get to work

  99. zinid

    Guus: I would propose something if I knew, I see no solution

  100. Zash

    Somehow attract people willing to spend their free time on making things better.

  101. zinid

    or somehow attract their money

  102. MattJ

    Charge users $1/year for using your app

  103. zinid

    MattJ: that didn't work, whatsapp was still unprofitable before the acquirement :D

  104. Zash

    Sell your soul to Facegoogle.

  105. Zash

    And your users data.

  106. zinid

    I have neither soul nor users data :(

  107. Zash

    Raise money for a marketing campain in order to raise money for writing a client.

  108. Zash

    Marketing marketing marketing!!

  109. SouL

    Uh, what do you want to do with me?

  110. Guus

    Sell you, obviously.

  111. mathieui

    SouL, sell you

  112. Zash

    One SouL, in mint condition, do I hear any bids?

  113. SouL

    Nooo

  114. SouL runs away!

  115. mathieui

    09:45:39 zinid> I think what we really need is more full-time developers, 95% of xmpp projects are maintained in spare time, most of the projects can barely survive 10-year period → I lightly updated the jabberfr wiki yesterday, it is full of clients dead in the last 10 years

  116. Zash

    Projects dying isn't necessarily a bad thing tho. Something something Darwinism.

  117. mathieui

    yeah

  118. mathieui

    but it’s bad because I’m the only one who updated the wiki after 2011

  119. mathieui

    so, "popular mobile clients" had J2ME and "popular clients" had coccinella

  120. Guus

    If we can't manage to update a wiki, I fear for development projects...

  121. mathieui

    Guus, that’s mostly because we had a very motivated guy doing it before then

  122. Guus

    Which, coincidentally, why I've started to help out with maintaining the stuff that we do have, as XSF.

  123. Guus

    mathieui: perhaps removing outdated data is better than keeping it unmaintained. Nothing puts people off as much as seeing information that's clearly incorrect.

  124. Guus

    I'm positive that things like that have a negative impact on people that consider contributing. I'm afraid we're loosing people, before they even started.

  125. Ge0rG

    Are the json files used for client list generation hosted on xmpp.org as well?

  126. Ge0rG

    We are losing people everywhere!

  127. Guus

    Ge0rG: referring to the software listing? Yes, used for all software

  128. Ge0rG

    Guus: not "used" but "hosted". The actual JSON files. So that external services could use them.

  129. Guus

    Ge0rG: that's my fear. The good news is that improving our data can be done by anyone. It's an easy PR away.

  130. mathieui

    Ge0rG, that’s why I started that

  131. mathieui

    that and adding conversations, chatsecure, xabber

  132. mathieui

    Guus*

  133. Guus

    Ge0rG: Ah, unsure. Well, you could always refer to the stuff in Github, but I don't think it was intended that way.

  134. Guus

    mathieui: thanks :)

  135. Zash

    Did we update the Prosody file?

  136. Guus

    "the Prosody file" ?

  137. Guus

    Prosody is listed on https://xmpp.org/software/servers.html, if that's what you mena.

  138. emxp

    zinid: i siggest first lets ask, how many money can we collect. and how can we spend it. what needs to happen to increase donations

  139. zinid

    emxp: where/whom to ask?

  140. Zash

    Oh, https://github.com/xsf/xmpp.org/commit/600d7f4d484c69ef3d631f40b7d65d9258015291

  141. emxp

    If XSF is okay to do task expanding the Protocol thats nice. but so far I didnt saw that they are not interestet

  142. emxp

    zinid: ask generally

  143. Ge0rG

    emxp: the XSF doesn't seem interested to do things beyond protocol development. And that's hard already.

  144. Zash

    > Do one thing, do it well.

  145. Zash

    And separation of concern.

  146. Guus

    especially because we're already having a hard time with that, I don't think the XSF should be taking on more.

  147. SouL

    Well, that would imply that XSF favours specific clients and such, if I understand correctly.

  148. Ge0rG

    SouL: not at all.

  149. Ge0rG

    There is plenty of possible improvement between "the XMPP protocol" and "Make Jabber Great Again"

  150. SouL

    Ge0rG, emxp would like to collect money for devs, or not?

  151. Ge0rG

    SouL: right, collecting money for developers would be rather hard.

  152. Guus

    But, again, if anyone wants to support clients: give the existing organizations your support. You really don't need the XSF for that.

  153. Ge0rG

    Either the XSF would create "the reference client" from that money, competing with XSF members, or it would have to devise a biased way to give money out.

  154. Ge0rG

    Guus: the existing client developers?

  155. MattJ

    XSF + reference client -> bad idea

  156. Kev

    Anyone + reference client -> bad idea, I think.

  157. Kev

    Not just the XSF.

  158. Guus

    Ge0rG: https://xmpp.org/software/clients.html

  159. Zash

    How long have people said "the xsf should do a reference test suite"? :)

  160. zinid

    reference server is a good idea! I have one to suggest :D

  161. MattJ

    Me too

  162. zinid

    2 reference servers is even better

  163. Ge0rG

    Guus: I know that page. My question was, whether you imply "client devs" by "existing orgs"

  164. Ge0rG

    Zash: a reference test suite would actually be something where I can see the XSF paying for development.

  165. Ge0rG

    Except that Daniel now almost implemented one.

  166. Zash

    Orly?

  167. Guus

    Ge0rG: I'm desperately trying to avoid naming names (as I'm personally involved in one of them) - but various clients have OSS organisations behind them that would gladly accept support.

  168. zinid

    what will the suite test?

  169. zinid

    servers?

  170. zinid

    because I don't know how to test clients

  171. zinid

    do we have shitty servers? no, we have shitty clients

  172. Ge0rG

    Guus: I'm not asking for names, but for clarification of your statement :)

  173. Ge0rG

    zinid: that's a blatant lie! We have shitty servers AND shitty clients.

  174. zinid

    no way

  175. Ge0rG

    zinid: you don't happen to be Evgeny from the ML?

  176. Zash

    https://en.wikipedia.org/wiki/Sturgeon%27s_law

  177. Guus

    Ge0rG: find the organization of the client that you want to see improved, then support them (either by joining as a dev, a community member, or by donating resources)

  178. zinid

    Ge0rG: that's me yes

  179. emxp

    Guus, SouL, Ge0rG: Yes, XSF shouldnt do an additional task. a new foundations may collect more money, because it is maybe more obvious where the money goes. if you can see projects

  180. emxp

    directly

  181. Ge0rG

    zinid: nice to meet you, and welcome to the XSF MUCs, where all the "inactive" members hang around :D

  182. SouL

    :)

  183. Guus

    Ge0rG: It's not just the developer that needs supporting, it's the entire organization (formal or informal) around the development effort. Some of our most valuable members write no code at all.

  184. Guus

    (That's where my distinction between Dev and Org originates)

  185. Ge0rG

    Guus: that's probably true. Still, sponsoring individual devs/dev-orgs is out of scope for the XSF, and rightly so.

  186. Guus

    ge0rG: I agree completely. I've been stressing that the XSF does not need to be involved, but instead, people could reach out to those dev-orgs directly.

  187. zinid

    yes, XSF should not collect donations

  188. zinid

    it's pointless, they need to share them somehow between projects, that's hard

  189. Ge0rG

    Guus: except there are no people who want to contribute significant amounts of money.

  190. Guus

    Sure it should. But not to sponsor one particular implementation.

  191. zinid

    Guus: and how to share between the projects? on what basis? equally?

  192. Guus

    Ge0rG: All I'm saying is that the XSF need not be involved if someone wants to do sponsoring of individual projects :)

  193. Guus

    zinid: you do not share at all. You use it for the activities that the XSF does itself.

  194. Ge0rG

    Guus: yes. But the more important question is: how can the XSF contribute to a future where we do have non-shitty clients and servers?

  195. zinid

    Guus: ah, ok

  196. Ge0rG

    zinid: the XSF can still pay for Summit Dinners and XMPP stickers.

  197. Ge0rG

    I wish we had Jabber stickers.

  198. Guus

    Ge0rG: facilitate development by having an up-to-date library of information (the XEPs, the Wiki, the webpage) and provide avenues for discussion (like this MUC - that still could use a web frontend - the mailinglists, and perhaps others).

  199. Ge0rG

    a web frontend for this MUC would require developing a web client.

  200. zinid

    regarding jabber tickers, isn't this XSF responsibility?

  201. zinid

    *stickers

  202. Guus

    Ge0rG: it further can host or be present at gatherings (like FOSDEM) and spread the love. Have meetings with stakeholders (even informal ones, like the Summit Dinner).

  203. zinid

    how to post stickers?

  204. Guus

    yes, the SCAM workgroup has stickers and leaflets and stuff, to be used in XSF activies like I described above.

  205. Ge0rG

    Guus: the XSF is doing that for 15 years, and we still have shitty clients and servers ;)

  206. Guus

    SCAM will (and has) happily send those out to people that are hosting such events.

  207. Guus

    Ge0rG: There is much that the XSF can (and is in process of) improve: the XEPs were completely outdating up until recently, the Obsevatory is still gone, the wiki and webpage have shown outdated information for a very long time, etc etc.

  208. Guus

    Ge0rG: getting that in order won't magically fix things, but it will surely facilitate - and it is stuff that we can do _now_, without needing to discuss what other activities we might want to spin up.

  209. Guus

    We're already stretched - adding more work won't improve things.

  210. Ge0rG

    Guus: indeed, you are right.

  211. Guus

    as a side-note: perhaps we should rename the 'experimental' status of a XEP. One of the recurring criticisms that I read is "Pretty-standard-feature XYZ has a XEP that is only "experimental"!

  212. SouL

    Yes, that's true.

  213. Guus

    it's just window dressing, but sometimes, that makes a difference.

  214. Ge0rG

    "draft" isn't much better either.

  215. Ge0rG

    Some XEPs live their whole life in "draft"

  216. mathieui

    Guus, what we need to do is either make the XEP status reflect real world perception, or add another status that does

  217. mathieui

    Ge0rG, did I mention that 0059 is still draft?

  218. Guus

    mathieui: I agree.

  219. Ge0rG

    0045 is fifteen years now, and still in Draft.

  220. Ge0rG

    There are probably XEP-0045 implementing developers younger than that.

  221. Flow

    That's why I think we should find a better name for Draft before thinking about what to do with experimental

  222. Zash

    "Work in progress", "Almost done", "Done" ? :)

  223. Ge0rG

    "Broken", "Stale" and "Rusty".

  224. Flow

    Zash: Doesn't actually sound that bad

  225. Ge0rG

    Zash: replace the last one with "Carved in Stone"

  226. Zash

    FINAL wait that's what it's called

  227. MattJ

    Skip that, jump to "Obsolete"

  228. Zash

    Hah

  229. Zash

    "Living document" -> "Dead document"

  230. MattJ

    +1

  231. MattJ

    Welcome to the internet

  232. Zash

    "Request For Comments"

  233. zinid

    what I personally would like to see is how many implementations support the XEP, and probably range the XEPs in this order

  234. zinid

    this is only what makes sense, because even Final can be implemented nowhere

  235. Zash

    zinid: Define support. Which leads back to the whole test suite thing.

  236. zinid

    Zash: claiming support is ok, even partial

  237. Zash

    Pretty sure Final requires two implementation.

  238. Zash

    s

  239. Ge0rG

    Zash: also goat blood sacrifices

  240. Zash

    Or was it Draft?

  241. Zash

    I forget

  242. zinid

    https://xmpp.org/extensions/xep-0009.html

  243. zinid

    this is final

  244. zinid

    where is it implemented?

  245. Zash

    Version 2.0 (2002-12-09) Per a vote of the Jabber Council, changed status to Final. (psa)

  246. SouL

    Could 'Subject to changes' be used for 'experimental', for example?

  247. SouL

    Or we should use just a word?

  248. zinid

    SouL: I think every XEP should be "subject to changes", we have namespace bumps

  249. zinid

    the only difference is probability

  250. zinid

    so "in development" and "more or less stable" is enough

  251. zinid

    dunno why there so many gradations

  252. Zash

    Experimental = "In active development"

  253. zinid

    still says nothing for me, I need to see where it's implemented

  254. Zash

    When it stops being in *active* development it goes into deferred

  255. Zash

    Similar to how IETF drafts expire after some months.

  256. Zash

    Should the XSF try to keep track of implementation status?

  257. zinid

    why not?

  258. zinid

    I don't think this is a lot of work

  259. zinid

    only creating some form

  260. zinid

    where everyone can submit

  261. Zash

    Periodic calls for experience?

  262. zinid

    no matter, something that would work without tons of pain

  263. Ge0rG

    What about a "compliance badge" that can be assigned after completing the compliance suite.

  264. Zash

    Maybe when things go deferred, send out a survey thing asking if anyone has been working on an implementation?

  265. Ge0rG

    This client fulfills [Jabber Gold Premium]

  266. Guus

    I've just posted on standards@ about the XEP status name change. I'm interested to see what others think of this

  267. Guus

    with that, I'm disappearing into the world of managers, deadlines and stale coffee.

  268. MattJ

    Don't do it!

  269. zinid

    Zash: "send out a survey" <-- where to send it?

  270. Ge0rG

    Mandatory JIDs everywhere!

  271. Zash

    The standards list

  272. zinid

    I think not so many people are in active conversation with XSF (list, chatroom, etc)

  273. zinid

    I almost never see Gajim devs in the list

  274. zinid

    maybe they are here?

  275. Zash

    Actually, I think the core of the proposal is to send out a call for experience along with the deferred message.

  276. zinid

    nah, I was suggesting to track the number of implementation right in front of XEP title or so

  277. Ge0rG

    Sounds like a task for a web service.

  278. Zash

    Figuring out if a XEP became inactive because everyone already implemented it or because nobody implemented it would probably be good.

  279. Ge0rG

    Zash: isn't that what "Final" vs. "Obsolete" is for?

  280. Zash

    Ge0rG: It's "Which direction should this Experimental XEP go?"

  281. goffi

    didn't follow the whole discussion, but about deferred, we may have nothing to add to a XEP, but waiting for implementation or something else before asking for move to draft. It would be nice to be able to do an update without modification, just to show it's not abandonned at all.

  282. zinid

    Ge0rG: a really simple submitting form is enough, which will put numbers in the database for displaying, I don't think this is brutally hard

  283. Zash

    There exists survey tools, if someone wants to automate it that way.

  284. Ge0rG

    zinid: web forms will be immediately overrun by spammers.

  285. zinid

    well, using existing tools is preferable of course

  286. zinid

    sigh

  287. zinid

    how others do this, cannot imagine

  288. Wiktor

    for the record, tracking progress for OMEMO is one github repository: https://omemo.top/

  289. Zash

    Could be as simple as adding "Have you implemented this? Send comments plz." on https://github.com/xsf/xsf-tools/blob/7628fe8610e3d7f2247e5e7634bbf6c754c2d033/xeputils/mail.py#L114-L125

  290. mathieui

    zinid, gajim devs are not in there, no

  291. zinid

    that's pitty because this is one of the most popular desktop client (although not everyone like it)

  292. zinid

    and we don't hear their opinion

  293. Guus

    so, get them in here :)

  294. goffi

    mathieui: Asterix is writing from time to time on @standard

  295. zinid

    we cannot force every developer joining this room or the list

  296. Guus

    Make them an offer they cannot refuse ;)

  297. mathieui

    the issue with gajim devs is that they really are busy (it’s mostly lovetox these days, with asterix showing up from time to time)

  298. zinid

    what I want to say is that we shouldn't expect lots of responses from developers and drawing conclusions based on received responses

  299. Ge0rG

    zinid: do you have a better proposal?

  300. zinid

    Ge0rG: tracking existing implementations is a good start in making some decision (such as deferring for example)

  301. edhelas

    maybe we could first track what XEPs are implemented in which clients

  302. Ge0rG

    zinid: but how?

  303. edhelas

    it's not that hard https://nl.movim.eu/?about#caps_widget_tab

  304. zinid

    Ge0rG: are we going circles? :) submitting form?

  305. zinid

    the point is everyone can submit

  306. zinid

    so even if developers are busy their users can submit

  307. zinid

    another advantage is of course everyone can decide about XEP popularity by implementations number

  308. zinid

    instead of experimental/draft/etc nonsense

  309. Zash

    Everyone implementing something doesn't make it good.

  310. Zash

    Good things don't usually win popularity contests in my experience.

  311. zinid

    really? in the context of standards?

  312. zinid

    which means the standard is crap? :)

  313. zinid

    do you remember such situation in xmpp?

  314. mathieui

    edhelas, caps widget is not enough

  315. Zash

    Good enough combined with timeing on the other hand.

  316. Zash

    Or marketing.

  317. edhelas

    the issue is, more than asking dev to be aware of new XEPs, is also to push them to deprecate or remove old ones

  318. edhelas

    mam:tmp, vcard_temp, Private XML…

  319. Zash

    vcard-temp and private xml are good enough, but not really that good

  320. Zash

    Multiple versions of the same XEP is a somewhat different issue.

  321. jonasw

    back

  322. jonasw

    goffi, if a XEP doesn’t have implementations, moving it to Deferred is a sane thing. There must be something wrong with it: either it has issues deterring implementors or it is not needed at all. Void updates are not going to make any of this go away.

  323. jonasw

    zinid, if users submit on behalf of their software, we’ll be getting incomplete and inaccurate data, that’s worse than no data.

  324. jonasw

    (e.g. "does this client support Jingle File Transfer?" "well yes of course, I can send files", but in fact the file transfer is using HTTP Upload)

  325. zinid

    jonasw: why would we have inaccurate data?

  326. zinid

    I don't say it would be 100% accurate

  327. Ge0rG

    zinid: because users are clueless.

  328. jonasw

    what Ge0rG says

  329. Ge0rG

    zinid: it would be 40% accurate and there would be multiple submissions.

  330. zinid

    Ge0rG: a clueless user who knows what xsf and xep is?

  331. Zash

    https://www.zash.se/xmpp-clients.html inaccurate!

  332. jonasw

    zinid, sure

  333. Ge0rG

    User often already fail at spelling a client name correctly.

  334. Zash

    If clients put XEPs into their marketing, then users will be somewhat aware of them.

  335. jonasw

    Guus, regarding donating money to client organizations: there are enough clients out there which do not have an umbrella organization

  336. zinid

    then what makes you think a developer is responding on your last calls?

  337. jonasw

    some of which are doing great work in the UX department (I heard dino is nice)

  338. jonasw

    accepting donations is tricky

  339. Ge0rG

    I'm working on a system for people with technical background, and they fail to properly spell their own name.

  340. zinid

    maybe that's a clueless user responding

  341. jonasw

    zinid, you got me thinking that we sohlud probably issue CFE and LC to the developers list too

  342. zinid

    jonasw: you need to find developers there first :)

  343. Ge0rG

    zinid: I think you just volunteered to create a web form, collect data from users, developers or goats, and to process it in a way that's suitable and useful to the XSF, thanks!

  344. jonasw

    khekhe

  345. zinid

    Ge0rG: sure, and you go develop ejabberd

  346. mathieui

    fair trade

  347. jonasw

    tough choice

  348. jonasw

    erlang vs. web development

  349. goffi

    jonasw: deferred != no implementation. I'm author of XEP-0355 and XEP-0356, they have 2 implementations (at least), and just didn't need to update them

  350. Ge0rG

    zinid: sorry, I've got my own client to develop, and I'm submitting issues for a bunch of others.

  351. goffi

    and they are deferred

  352. goffi

    anyway I now need to update them so it's not a big deal.

  353. jonasw

    goffi, if there are two implementations, you should ask for advancement to Draft.

  354. goffi

    jonasw: now, because I need more tests

  355. goffi

    too early for that

  356. Ge0rG

    zinid: but while you are here, you can solve my ejabber MUC bug: all MSN clients are kicked when one of the MSN clients sends an error to the MUC.

  357. goffi

    s/now/no/

  358. Guus

    jonasw: clients without organiations typically have one developer. Donating then often is done in the form of temporary commisions ("can I hire you to build this-and-this in the client"). Nothing dangerous about that.

  359. jonasw

    Guus, it is massively tricky if you are employed elsewhere

  360. jonasw

    I am kind-of glad that we didn’t get into the Prototype Fund, because I didn’t want the headache of coordinating with my employer and insurance etc.

  361. jonasw

    (maybe that’s only a german thing that these things are complicated)

  362. zinid

    Ge0rG: I cannot drop my tasks and fix your issue, create a github issue maybe? if there is a bug it will be fixed quite fast

  363. Ge0rG

    zinid: I'm not the server operator, so I don't have logs.

  364. Guus

    jonas: true, that can be tricky. For me personally, it's not been a problem, as when I was employed, I've always made sure to have a clause in my contract that allowed for it. Now that I'm self-employed, things are even easier. But yes, it does require some planning.

  365. jonasw

    Guus, I don’t even know how such a clause would need to look like, really.

  366. Guus

    perhaps we could facilitate that planning in some way, shape, or form - simply by letting people interested get in contact with people with experience.

  367. zinid

    Ge0rG: I can only say I will check if I don't forget (like always)

  368. Ge0rG

    zinid: also you seem to have enough time to make proposals here and on standards@ .P

  369. zinid

    Ge0rG: nice try :)

  370. Ge0rG

    zinid: you know, I've once waited multiple years on an ejabberd ticket. Then I gave up and switched to prosody.

  371. Guus

    jonasw: from exprience, every employment contract that I signed (which have been 4) had a non-compete. When discussing the contract, I'd mention: "but i do work on ... which I'd like to continue doing" after which we had some back-and-forth, and a clause was added.

  372. Guus

    I might've been lucky, unsure, but it always worked out.

  373. zinid

    Ge0rG: and now waiting years on prosody tickets, ok

  374. Guus

    (and it has the added bonus of having HR work out the details of the clause :P )

  375. jonasw

    Guus, right, will take that into account when I get my employment contract soon-ish

  376. mathieui

    Guus, my employment contract has a "all your personal work belong to us, even outside of work time", and I ignore it because it’s illegal, but meh

  377. jonasw

    mathieui, wtf

  378. SouL

    I thought they would do that only in the USA

  379. Ge0rG

    zinid: EJAB-532 took four years for a community workaround. I've got two more years to go with prosody before reaching that timeout.

  380. Guus

    mathieui: I don't recommend knowingly accept a contract and disobey it, even if it's an invalid contract.

  381. Ge0rG

    Guus: sometimes that's better than not having an income.

  382. Guus

    i've always had my feedback on a contract draft addressed by HR - but again, that might be lucky.

  383. zinid

    Ge0rG: so what is your conclusion? every ticket takes years to resolve? this is not true of course, you can check dynamics on github

  384. Guus

    Ge0rG: I was assuming that it wasn't even discussed before signing it.

  385. Guus

    Ge0rG: if it *was* discussed (but still disallowed), then I'd more so advice against breaking it!

  386. Ge0rG

    Guus: I've had a talk to my now-boss regarding illegal parts of the contract, and he said "we've got that in all contracts, we won't make an exception", so I shrugged it off.

  387. Guus

    Ge0rG: I might have been lucky with my employers then. Might be a cultural thingy difference between the types of organisations we work for.

  388. daniel

    And this is what happens if you don't have unions

  389. jonasw

    daniel, does conversations.im already have a union? :)

  390. Guus

    the boss wouldn't allow it! ;)

  391. Guus ducks, runs

  392. Ge0rG

    daniel: don't go Set Theory on us!

  393. mimi89999

    What?

  394. Ge0rG

    unions, intersections, etc.

  395. jonasw

    now we’re at traffic managment!

  396. mathieui bangs the on-topic gavel

  397. jonasw moves out to xmpp@

  398. Guus

    who can give SCAM-wg access to the XSF twitter account?

  399. goffi

    mathieui: for my last job in France, I've made the company bosses sign a paper saying they knew that I was working on my project on my free time, and wouldn't claim any right on it.

  400. goffi

    mathieui: anyway, I don't think they have any right on what you're doing on your freetime, whatever the contract is saying (but I'm not a lawyer of course)

  401. pep.

    Zash> If clients put XEPs into their marketing, then users will be somewhat aware of them. < I'm thinking more and more users shouldn't be aware of the impl. details (i.e., XMPP). But maybe it was sarcastic and I didn't catch it

  402. zinid

    pep.: true

  403. edhelas

    well depends to who you're doing "marketing"

  404. edhelas

    when I'm doing release notes I can go into lots of XMPP details but I prefer most of the time to stay with "upload files feature" with a reference to the XEP than explaining the whole stack

  405. pep.

    edhelas, sure

  406. Zash

    Go to various clients web pages, search for XEP, count matches.

  407. pep.

    I'm not talking about devs, nor poezio (console client) users

  408. Ge0rG

    I think there was recently a proposal for a formal client description language, including XEPs.

  409. jonasw

    indeed

  410. jonasw

    that’d also work for gathering implementation stats by the way

  411. edhelas

    jonasw are you talking about https://github.com/movim/moxl#xmpp-support or https://github.com/dino/dino/wiki/Supported-XEPs ?

  412. jonasw

    neither I think

  413. jonasw

    let me get you a link

  414. jonasw

    edhelas, https://mail.jabber.org/pipermail/standards/2017-August/033123.html

  415. edhelas

    okay :)

  416. jonasw

    goffi, care to reply to daves email on standards@ with your example?

  417. jonasw

    I think it’s relevant to the discussion

  418. goffi

    jonasw: sure

  419. dwd

    goffi, '355/356? If they "don't need updating", then they're surely ready for advancement?

  420. mathieui

    dwd, "I now need to update them"

  421. goffi

    dwd: I have now updates to put. The thing it take time to have implementation, and it take time to implementation to mature. For instance in the case of 355 I've realized that disco items were not handled correctly in my Pubsub service, and this need a slight change in the XEP. I'm using this Pubsub service with XEP-0355 for more than one year, but I've just realized this was missing a couple of weeks ago, and I wanted to test implementation before modifying the XEP.

  422. dwd

    Either the XEP *is* expected to change in an unstable manner, or else it's ready for advancement. If it's expected to change in an unstable manner but isn't being actively edited, then it gets deferred after a year. Which part of this are you objecting to?

  423. goffi

    dwd: I'm not objecting to anything, I just say that the XEPs are deferred but not abandonned, just on hold. I'm writing an email on standard@ to explain that.

  424. SamWhited

    > I don't think this is a lot of work Yes it is. No matter what the thing is, if someone says those words they're wrong or they would have done it already.

  425. dwd

    SamWhited, I don't even know what you['re quoting, and I agree.

  426. SamWhited

    dwd: Yah, those words were said earlier (about something that I suspect editors would end up having to do).

  427. SamWhited

    It made me cringe. I still think our process is too complicated and that we've already forgotten about it again because we have new editors that are rosie eyed and not burnt out yet so work is getting done and we'll ignore the problem until they get burnt out and we get new editors again.

  428. SamWhited

    But it applies in general too.

  429. dwd

    SamWhited, I think our process has acrued a lot of cruft and assumptions and special cases that it shouldn't have (and isn't even documented to have).

  430. SamWhited

    dwd: Indeed, it needs some love.

  431. dwd

    SamWhited, I think understanding what it was meant to be would be useful. The fact people think we need a stage before Experimental suggests to me that it's very poorly understood.

  432. SamWhited

    dwd: I agree

  433. jonasw

    dwd, the question is whether that lack of understanding comes from lack of documentation, lack of active education or something else

  434. jonasw

    in any case, if newcomers or people taking only a quick look don’t understand it, it’s a PR problem we should fix. and that often has to do with naming

  435. dwd

    jonasw, I don't think it's well documented, and I don't think people read that document very closely. In addition, this problem has become acute because we've lost a chunk of our institutional knowledge - lots of long-term (ie, decades not months) community people have drifted away over the past year or two.

  436. dwd

    jonasw, There's other problems with our process too, like no (real) IPR policy, and no appeals process. Both block us from being "Open Standards" in the openstand.org sense.

  437. SamWhited

    Actually, I agree and disagree. I agree that "draft" is poorly misunderstood and think that we should rename it (it doesn't "sound like" the name implies "you should implement this, it's done"). I think experimental is fine and people probably do understand it (it's experimental and you should only implement it if you're comfortable implementing things that might change). The problem with experimental isn't one of naming, it's that we leave things in experimental too long.

  438. Kev

    "it's experimental and you should only implement it if you're comfortable implementing things that might change" The same is true of Draft - they *might* change, we just try not to.

  439. Kev

    (Actually, that's not true, we try not to in ways that are backward incompatible)

  440. dwd

    SamWhited, I agree with you. But that doesn't explain people who want us to have a stage before Experimental, or who want XEPs to meet certain quality gates before Experimental, and so on.

  441. SamWhited

    s/that might/that are likely to/

  442. SamWhited

    dwd: Ah yah, fair. I do think that's misguided. I do think a basic quality gate is fine though, it should at least be possible for me to implement it before it goes to experimental.

  443. dwd

    Kev, We generally don't change Experimental in ways that aren't backwards compatible - we're just (more) open to abandoning the namespace and minting a new one with namespace versioning.

  444. Kev

    I think 'Not obviously stupid and not duplicating existing stuff with no clear differentiator' is the check I used to do for +1ing Experimental.

  445. Kev

    dwd: Changing the required namespace is about as backwards incompatible as you can get.

  446. Kev

    When talking about compatibility of the document, not of a particular namespace within it.

  447. dwd

    Kev, Well, sorta. The old namespace still works, nothing is broken. But yes, it's a clean break rather than maintaining interop.

  448. SamWhited

    Added a card for board to discuss the rename.

  449. SamWhited

    And one on council to make a recommendation.

  450. Guus

    renaming draft to stable and striving to not keep things in 'experimental' for to long would be big wins, I think.

  451. jonasw

    I agree

  452. Guus

    if, on top of that, we can apply structural simplifications to the entire process, even better. Suggestions?

  453. jonasw

    I’m currently fine with the XEP editing process, mostly because I automated the parts which can be automated (and which I had contact with, there’s some stuff I haven’t done yet, like Last Call)

  454. Guus

    jonasw: but you fall in Sams 'new-and-not-yet-burned-out' category :)

  455. jonasw

    maybe

  456. jonasw

    the level of automation helps against burning out though

  457. jonasw

    needs moar autmoation though

  458. Zash

    Always moar automation

  459. jonasw

    I need to figure out how to make a github bot which can post metadata of all touched XEPs in a PR

  460. Guus

    absolutely, but automation needs maintenance too.

  461. jonasw

    it is annoying to have to look up the status and authors of a XEP manually inside a diff

  462. Guus

    I'm heading out again, but I'd be very interested in hearing practical improvements that we can make to the process.

  463. jonasw

    something which detects when a namespace bump must happen would be amazing

  464. jonasw

    but I doubt that’s possible

  465. jonasw

    (maybe something which warns when RFC 2119 words are touched)

  466. Kev

    Which doesn't imply that it needs a namespace bump.

  467. jonasw

    I know

  468. jonasw

    but it’s still something good to see quickly when processing a PR

  469. jonasw

    I’m bad at reading diffs

  470. Zash

    jonasw: Any diffs or XEP XML diffs in particular?

  471. jonasw

    Zash, XEP diffs are especially bad because of long lines

  472. SamWhited

    I can read diffs fine. I can barely read XEP XML when it's not a diff.

  473. jonasw

    or alternatively, because of line-broken text

  474. Zash

    Anyone wanna continue my work on turning xeps into text/markdown for simpler diffs?

  475. jonasw

    Zash, dump the code somewhere, I may take a look

  476. jonasw

    doesn’t help much when viewing diffs on the repository online though

  477. SamWhited

    Jokes aside, as much as I like the idea I don't think we need more tooling, more things to maintain, more stuff to break, or more things you have to know about and learn to use.

  478. SamWhited

    Which is a long way of saying what jonasw just said

  479. jonasw blinks

  480. jonasw

    I’m not sure how I said that

  481. SamWhited

    > doesn’t help much when viewing diffs on the repository online though

  482. jonasw

    ah

  483. jonasw

    well, actually, in the back of my head I mentally added it to the list to integrate in a possible github app for which I have an idea

  484. jonasw

    I need to take a look at the effort involved. Something which is geared towards XEP PRs and can do a great deal of the initial triaging process automatically and/or simplify the triaging by putting all relevant information in once place would be amazing.

  485. Zash

    jonasw: https://gist.github.com/Zash/372591d4c61b6af70d810a78bd1af12d

  486. jonasw

    Zash, can you dump a quick list of todos below that?

  487. Zash

    jonasw: I think the main blocker for me is that I don't know how to proceed, or what to do with it.

  488. jonasw

    from what I can tell it converts xep-xml to markdown, right?

  489. Zash

    The Lua thing does that, yes. One shell script to normalize its input and one that picks two versions of a file out of git and compares them with the previous scripts.

  490. Guus

    SamWhited, so what _does_ help?

  491. SamWhited

    Guus: What does what help?

  492. Guus

    You earlier referred to a benefit of making 'the process' less complex. I agree with pretty much everything that you wrote, but I'm still not sure what a pragmatic improvement would be.

  493. SamWhited

    Guus: I wrote a long email about this actually, I will forward it to you if I can find it. There's also a trello where I put a few of the potential improvements

  494. SamWhited

    Some of them have been done, it's definitely a bit nicer now

  495. Guus

    if there are sensible improvements left, by all means, lets implement them.

  496. Guus

    let's put things on the radar of those that are to decide on things.

  497. SamWhited

    The only two things left that I think we could reasonably do are automating email (sounds like jonasw is working on that a bit, we'd just have to integrate it with the build) and automating archival of XEPs as part of the build (I still have no idea if we have an attic or how it works in the new docker land, so if that still needs to be fixed it might end up being a lot more work)

  498. Guus

    ah, okay, that's automation. I though you were referring to procedural changes (eg: make XEP-0001 less complex, or something in that nature).

  499. Zash

    A thing that I've wondered about is, is there a good way to XEP versions to commits?

  500. SamWhited

    Oh I see, sorry

  501. Zash

    A thing that I've wondered about is, is there a good way to map* XEP versions to commits?

  502. Guus

    not to say that the automation bit wouldn't be wildly helpful.

  503. SamWhited

    Zash: not really; I was going to suggest some git foo, but apparently some XEPs have multiple revisions with the same version or where a version ended up going backwards somehow.

  504. SamWhited

    So maybe we need to improve CI as well

  505. Guus

    SamWhited: maybe it's worth manually revamping those XEPs, for the greater good?

  506. SamWhited

    Guus: Yah, I'll do it for the one I noticed and add a task to add a CI step to find any others (and then fix those if there are any more)

  507. jonasw

    SamWhited, yes, there’s a workin gattic

  508. jonasw

    SamWhited, yes, there’s a working attic

  509. jonasw

    I forgot to mention that there’s a script to copy changed XEPs into the attic, again based on xeplist.xml

  510. Guus

    awesome! So only the email bit remains an issue for now?

  511. jonasw

    not really

  512. jonasw

    I just want to test the tooling a bit more on real-world cases

  513. jonasw

    then it can easily be integrated into the deploy step on the server

  514. jonasw

    at least I think I fulfilled the wishlist I was given by Kev to make that happen easily

  515. Guus

    so, you're saying that both issues are well under way to being fixed?

  516. jonasw

    indeed

  517. SamWhited

    Fantastic :)

  518. Guus

    more awesome!

  519. Guus

    Sam, I think you need to come up with a new list of things that aught to be improved :)

  520. Guus

    I'm going to pick up the kids

  521. Guus

    ttyl

  522. zinid

    Ge0rG: https://github.com/processone/ejabberd/commit/e1efd291568aae29ac06f507c8b0bbf60b65d91a

  523. zinid

    Ge0rG: there is another MSN-related bug reported by edhelas, hehe: https://github.com/processone/ejabberd/issues/2007

  524. edhelas

    I'm keeping the ejabberd team busy these days

  525. zinid

    :D

  526. zinid

    edhelas: your bug is surprisingly harder to fix, unlike Ge0rG's one

  527. zinid

    due to shitty code of mod_muc

  528. edhelas

    :p

  529. Ge0rG

    zinid: thanks very much.

  530. Ge0rG

    Holger: time to git-pull conversations.im! ;) ^ https://github.com/processone/ejabberd/commit/e1efd291568aae29ac06f507c8b0bbf60b65d91a

  531. zinid

    Ge0rG: Holger is working on this

  532. zinid

    he's busy porting his patches to this new ejabberd version (17.x is a lot different)

  533. edhelas

    zinid I never report easy bugs, I prefer the tricky ones :p

  534. mimi89999

    zinid: What else than the pubsub patch?

  535. zinid

    mimi89999: are you about Holger? Stuff regarding registration and so on

  536. mimi89999

    Ah, the things really specific to conversations.im

  537. zinid

    yep

  538. Tobias

    https://signal.org/blog/private-contact-discovery/

  539. jonasw

    hm

  540. jonasw

    nice, but not really applicable to XMPP, is it?

  541. jonasw

    you’d still need to figure out which server to ask and you’d still need some directory trusted for mapping some_identifier -> JID

  542. Holger

    Oh yay, zinid is the best.

  543. Holger

    mimi89999: Yes conversations.im-specific things ... and dirty hacks :-)

  544. SouL

    We all love dirty hacks.

  545. pep.

    No we don't, but they stick around :(

  546. pep.

    No we don't, and they stick around :(