XSF Discussion - 2020-06-17


  1. Daniel

    edhelas: JSXC does the same thing with the parameter values that's why I dug up the issue

  2. edhelas

    ok :)

  3. flow

    re https://github.com/xsf/xeps/pull/715 (and https://github.com/xsf/xeps/pull/961): dwd summarized it nicely in the council meeting just a few minutes before. If we keep the xep30 requirement that there must be a disco#info feature in the response, then not adhering to it in examples appears to me not like omitting an optional feature, but omitting an required namespace declaration. Hence I feel like we have to choose one of either fixing the examples, or, removing the requirement

  4. flow

    dwd's suggestion of "disco#info MAY be elided if other features are present" seems like a good compromise

  5. pep.

    I haven't read this part of the council meeting, but just reading this I'd say there are lots of non-compliants examples already and we're not taking steps to fix them. Disco examples will almost never be valid anyway due to omissions/ellipsis characters ("..."), making them invalid XMPP in the first place

  6. pep.

    Also, examples are non-normative

  7. flow

    sure, but that doesn't mean we should not fix them if we can

  8. pep.

    I don't think modifying the spec in this case is necessary tbh

  9. pep.

    I agree with jonas here, "-1, unless the author can find real-world issues which are solved by this PR."

  10. pep.

    Not non-normative examples

  11. pep.

    flow, so if I understand correctly, the issue is that the disco#info feature is missing from all these examples?

  12. pep.

    Add it? :P

  13. flow

    pep., that is what I tried first

  14. flow

    see pr #715

  15. pep.

    Right, hence jonas’ suggestion to use <!-- ... --> seems fine

  16. flow

    I think that is fine for optional features, but 'disco#info' is a required feature right now

  17. flow

    but yeah, I see how this is probably just me being pedantic

  18. pep.

    So you're going to go through all examples of all XEPs and fix XEPs accordingly? :/

  19. pep.

    Instead of fixing examples

  20. Ge0rG

    flow: as was said repeatedly, adding all mandatory features into all XEP examples won't help anybody.

  21. Ge0rG

    but adding `<!-- ... -->` would actually improve readability (and also make sure that you can't just copy&paste everything from the example)

  22. pep.

    flow, tbh I'd also like if examples were correct. But I think that's a bit far fetched judging that it's already not valid XMPP anyway

  23. Ge0rG

    IIRC, when #751 was rejected, "add ... comments to examples" was the recommended way forward.

  24. flow

    Ge0rG, I don't think there are many mandatory features at all

  25. flow

    right now, it's just one

  26. Ge0rG

    flow: yes, but even a few mandatory features distract from the feature that the respective example is about

  27. flow

    again, one, but I also would favor changing the xep30 requirement

  28. Ge0rG

    flow: you are probably aware that this is not going to happen for a Final document.

  29. flow

    Besides I wonder how helpful the disco#info examples in XEPs really are. Seems very repetitive, but maybe that's only me having read a ton of XEPs,

  30. Ge0rG

    In my unchanged-for-the-last-two-years opinion, adding the disco#info feature to examples of other XEPs than 0030 is only going to distract the reader.

  31. pep.

    flow, tbh I also think they are mostly not necessary

  32. flow

    Ge0rG, that's just like your opinion, man

  33. pep.

    :D

  34. pep.

    Just saying "this is a feature you should declare: XXX" should be more than enough

  35. flow

    pep., I was thinking about adding a example section to xep 30 that xeps could refer to, ideally this section would also forward the reader to xep30 caching mechanisms like xep115 and caps2

  36. pep.

    yeah if you really want to, that may be good to have

  37. flow

    uh, and that

  38. flow

    uh, and that lebowski quote was meant as reply to modifying final xeps. I do agree, of course, that every unnecessary information is a distraction.

  39. Ge0rG

    so let's agree on this: there are many places in the XEPs that can be improved

  40. jonas’

    16:30:04 flow> Ge0rG, that's just like your opinion, man

  41. jonas’

    don’t use my moves to make me agree with you!!!

  42. jonas’

    pep., it would indeed be nice if we had an overview, in each XEP, about the '30 features it defines with links to the text which explain them. that would also make stuff like the examples obsolete

  43. Ge0rG

    a feature registry!

  44. pep.

    Too early

  45. pep.

    Too soon

  46. Ge0rG

    if only we had xml in the XEP schema to define registry elements that could be pushed automatically

  47. pep.

    You'd still need to document features, but yeah that'd be cool

  48. Ge0rG

    that magic xml could also automatically generate a well-formed example in the XEP

  49. Ge0rG

    ...where I'd still insist on the example containing <!-- ... --> instead of the disco#info feature

  50. pep.

    I'd rather have an element in the XEP to define disco features rather than a more involved example that's probably harder to parse and that can be regenerated via xslt aftewards

  51. jonas’

    pep., good idea actually

  52. Zash

    indeed

  53. jonas’

    we could extend xep.dtd and xep.xsl to support that

  54. pep.

    I still think these disco examples are useless nonetheless

  55. Zash

    we could 🥁️ use namespaced elements!

  56. jonas’

    put a <disco:describes feature="..."/> element in a section, boom.

  57. Zash

    XEP Extension XEP?

  58. pep.

    Yo Zawgsh

  59. Ge0rG

    yeah, I was thinking about a sort of a new custom element to define that.

  60. pep.

    So I'm thinking about that minutes taking bot. What would we want it to do exactly? Would that really alleviate important work from the actual minute taker?

  61. pep.

    Seems easy to have the bot take motion results, start/end of a meeting, actions, but I don't really see it summarize everybody's opinions

  62. jonas’

    I think to be useful it’d have to actually record motions and results

  63. pep.

    And the latter is to me the most important

  64. jonas’

    there was that meetingbot...

  65. jonas’

    IRC based, which seemed to be quite reasonable

  66. pep.

    Yeah I'm not looking for an implementation, just requirements

  67. pep.

    Trying to understand if it's just smoke and mirrors or if it's actually gonna be of use

  68. pep.

    I'm looking at some examples outside of the XSF: - GNOME: guidelines: https://wiki.gnome.org/FoundationBoard/Minutes/Guidelines, example: https://wiki.gnome.org/FoundationBoard/Minutes/20200330, https://wiki.gnome.org/FoundationBoard/Minutes/20200413 - SPI: https://www.spi-inc.org/meetings/minutes/2020/2020-04-13/ https://www.spi-inc.org/meetings/minutes/2020/2020-03-09/

  69. pep.

    GNOME minutes seem pretty complete, everybody seems to participate in the writing, during the meeting, even if there is somebody (secretary or deputes) responsible for them

  70. pep.

    SPI minutes seem a bit poor to me. I know they use an irssi plugin to get vote results, but otherwise there's no reported chats in there

  71. pep.

    So.. while I'm happy to have a bot help with keeping track of decisions and stuff, to me that's not solving the issue

  72. pep.

    But I guess I'll make this point again tomorrow..

  73. pep.

    Or when a bot comes up

  74. Ge0rG

    One day, a bot will take over the XSF