XMPP Council - 2017-11-08


  1. Tobias has joined

  2. vanitasvitae has left

  3. daniel has left

  4. Tobias has joined

  5. Tobias has joined

  6. Tobias has left

  7. daniel has left

  8. daniel has left

  9. Tobias has joined

  10. daniel has left

  11. daniel has joined

  12. daniel has left

  13. daniel has joined

  14. daniel has left

  15. daniel has joined

  16. jere has left

  17. daniel has left

  18. daniel has joined

  19. daniel has left

  20. jere has joined

  21. daniel has joined

  22. jere has left

  23. daniel has left

  24. daniel has joined

  25. SamWhited has left

  26. daniel has left

  27. daniel has joined

  28. daniel has left

  29. daniel has joined

  30. daniel has left

  31. daniel has joined

  32. daniel has left

  33. daniel has joined

  34. daniel has left

  35. daniel has joined

  36. daniel has left

  37. daniel has joined

  38. genofire has joined

  39. ralphm has left

  40. daniel has left

  41. daniel has joined

  42. ralphm has left

  43. SamWhited has left

  44. daniel has left

  45. daniel has joined

  46. daniel has left

  47. daniel has joined

  48. daniel has left

  49. daniel has joined

  50. ralphm has left

  51. daniel has left

  52. daniel has joined

  53. jcbrand has joined

  54. daniel has left

  55. daniel has joined

  56. ralphm has joined

  57. Tobias has joined

  58. daniel has left

  59. daniel has joined

  60. Tobias has joined

  61. daniel has left

  62. daniel has joined

  63. ralphm has left

  64. jcbrand has left

  65. ralphm has left

  66. Kev has joined

  67. jcbrand has joined

  68. ralphm has left

  69. Zash has left

  70. Zash has left

  71. Zash has left

  72. Zash has left

  73. Zash has left

  74. Zash has left

  75. Zash has left

  76. daniel has left

  77. ralphm has left

  78. Syndace has left

  79. daniel has left

  80. Zash has left

  81. Ge0rG has joined

  82. daniel has left

  83. daniel has left

  84. daniel has left

  85. ralphm has left

  86. ralphm has joined

  87. jonasw

    I’d like to add "Revisit BMH in the context of Styling" on the Councils agenda for today, but I don’t want to abuse my editor powers to do so, so I’ll just drop this here.

  88. daniel

    when (and by whom) was this vetod upon? I can't find the minutes for that

  89. jonasw

    Link Mauve

  90. jonasw

    2017-10-18

  91. jonasw

    and SamWhited

  92. jonasw

    but I don’t see rationales

  93. Zash

    Does that mean it was actually accepted?

  94. Ge0rG

    No, -1 is a veto

  95. Zash

    I'm trying to figure out if a rationale is required :)

  96. Ge0rG

    I'd be surprised if not.

  97. Kev

    It is required that anyone vetoing provides a rationale, but a rationale isn't required to veto :)

  98. Kev

    I believe.

  99. jonasw

    I am confused, Kev.

  100. Zash

    I can barely parse that sentence. I blame the coffee.

  101. Ge0rG

    Me neither. And I've got enough coffee to rule out that source of confusion.

  102. Zash

    The word "veto" isn't in XEP 1

  103. Zash

    "object" it says

  104. Ge0rG

    "confusion" can also result if you remove a substring of "coffeine infusion"

  105. jcbrand

    Ge0rG: unfortunately in English it's caffeine

  106. Ge0rG

    "confusion" can also result if you remove a substring of "coffee/? infusion"

  107. Zash

    > If objections are raised by the Approving Body on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.

  108. Ge0rG

    s/coffeine/coffee

  109. jcbrand

    :)

  110. Ge0rG

    Sigh.

  111. Zash

    caffeine?

  112. jcbrand

    yes please

  113. Ge0rG

    LMC with regex fail

  114. jcbrand

    Coffee contains caffeine. Kaffee beinhalted Koffein (funny mirroring there)

  115. jonasw

    indeed

  116. jonasw

    Kev, can you clarify your statement?

  117. genofire has left

  118. Kev

    Anyone vetoing a protoXEP needs to provide a rationale, but that doesn't mean that failing to do so magically accepts the XEP.

  119. jonasw

    Kev, that makes more sense, thanks.

  120. Ge0rG

    So SamWhited is currently in violation of XEP-0001...

  121. jonasw

    (so is Link Mauve, I think, at least on the list record I can’t easily find a rationale)

  122. jere has joined

  123. Kev has left

  124. Kev has joined

  125. Ge0rG

    Damn, so I've violated 0001 as well.

  126. Ge0rG

    jonasw: <Link Mauve> I’ve already read it yesterday evening, and I’m very much -1 on it due to the concept of waiving any format support, forcing implementations to support multiple formats and making it impossible for a message to carry more than one (think MUC for example).

  127. jonasw

    Ge0rG, that’s not on-list unfortunately, but good to have

  128. Ge0rG

    jonasw: it's in the logs.

  129. daniel has left

  130. jere has left

  131. jere has joined

  132. daniel has left

  133. daniel has joined

  134. Kev has left

  135. Kev has joined

  136. Kev has left

  137. jere has left

  138. jere has joined

  139. Kev has joined

  140. genofire has joined

  141. ralphm has left

  142. Syndace has left

  143. ralphm has left

  144. Flow has left

  145. Flow has joined

  146. Tokodomo has joined

  147. daniel has left

  148. daniel has left

  149. daniel has left

  150. jere has left

  151. jere has joined

  152. daniel has left

  153. jonasw has left

  154. daniel has left

  155. ralphm has joined

  156. Tobias has left

  157. ralphm has left

  158. ralphm has left

  159. Ge0rG has left

  160. Ge0rG has joined

  161. Ge0rG has left

  162. Ge0rG has joined

  163. Ge0rG has left

  164. Ge0rG has joined

  165. Syndace has joined

  166. genofire has joined

  167. georg has joined

  168. georg has left

  169. Ge0rG has left

  170. Ge0rG has left

  171. daniel has left

  172. Link Mauve

    Hi, it’s time.

  173. daniel

    I'm here

  174. Link Mauve

    Ping Tobias, SamWhited, dwd.

  175. Tobias

    pong

  176. Tobias

    Link Mauve, you want to run the meeting?

  177. Link Mauve

    I can do that yeah. :)

  178. SamWhited

    oops, I am still confused and thought it was in an hour. I also am here though.

  179. dwd

    Pang?

  180. Tobias

    go ahead :)

  181. Link Mauve

    So 1) roll call.

  182. Link Mauve

    Everyone’s here.

  183. Tobias

    here

  184. Link Mauve

    2) any minute taker?

  185. jcbrand

    I'm available

  186. dwd

    \o/

  187. Tobias

    great, thanks

  188. jere has joined

  189. SamWhited

    Tobias: grooming Link Mauve for command I see!

  190. Tobias

    SamWhited, :)

  191. Link Mauve

    3) Styling it seems.

  192. daniel has left

  193. Link Mauve

    So, we have two proposals.

  194. Link Mauve

    Which is great!

  195. Tobias

    https://xmpp.org/extensions/inbox/styling.html

  196. dwd

    And also, which is great?

  197. Link Mauve

    And https://xmpp.org/extensions/inbox/markup.html

  198. Tobias

    trello just mentions one of them

  199. Link Mauve

    Oh?

  200. Link Mauve

    jonasw sent the second one yesterday, maybe we forgot to add it.

  201. dwd

    This is the next meeting for both, so we should properly consider them now.

  202. Link Mauve

    It has had a proper announce email anyway.

  203. Tobias

    Link Mauve, but we probably want to vote on each individually, not?

  204. Link Mauve

    With these proposals, I’m finally happy with deprecating XHTML-IM, it seems jonasw took into account every criticism I’ve seen on the mailing list in all threads that have been talking about it recently.

  205. Link Mauve

    Tobias, sure, but we will vote on them next week.

  206. Tobias

    ah..ok

  207. dwd

    Link Mauve, I don't follow - vote on what next week?

  208. SamWhited

    Don't we normally vote in the first meeting after a submission (or on list, of course)?

  209. Link Mauve

    (IIRC we have two weeks to vote on accepting a ProtoXEP, I can start the vote right away if you prefer.)

  210. dwd

    Link Mauve, Two weeks to vote, starting at the next meeting.

  211. dwd

    This being the next meeting.

  212. Link Mauve

    Ok.

  213. Link Mauve

    So let’s start.

  214. Link Mauve

    4) Vote on styling.html

  215. dwd

    +1.

  216. daniel

    +1

  217. Link Mauve

    On list.

  218. SamWhited

    +1, naturally

  219. Tobias

    +1

  220. Link Mauve

    Perfect.

  221. Link Mauve

    5) Vote on markup.html

  222. Link Mauve

    +1

  223. dwd

    SamWhited, You say naturally but XEP authors have voted against their own XEPs in Council before, you know.

  224. Tobias

    on list, haven't read that one yet

  225. Ge0rG has left

  226. daniel

    +1

  227. SamWhited

    dwd: I'd love to hear the story there

  228. SamWhited

    On list.

  229. dwd

    I'm +1 on this too. I don't think I want both, ultimately, and would prefer the other, but I'm not going to die on this hill if I can avoid it.

  230. Link Mauve

    The other one has seen a lot of criticism, before and after the proposal (it basically ignored most of the arguments against this approach), this one has only the downside of OTR and such not playing well with it; arguably OTR already has its own styling mechanism (it carries HTML).

  231. Tobias

    yeah. I think we shouldn't let restrict us by ancient OTR

  232. dwd

    Link Mauve, It is possible to take notice of arguments without agreeing with them, you know.

  233. moparisthebest has joined

  234. SamWhited

    Alternative take: most of the critisism was addressed and the responses were ignored, but maybe this isn't the time and the place to be throwing statements like that around.

  235. Link Mauve

    dwd, of course, but it ignored all of the arguments against Markdown not to name it.

  236. Link Mauve

    Anyway, let’s move on.

  237. Link Mauve

    6) 0146 obsoletion.

  238. Link Mauve

    This has happened since last week, so I just archived the card.

  239. SamWhited

    Sorry for the delay on that

  240. dwd

    Link Mauve, No, I'm not comfortable moving on when you're accusing others of *ignoring* arguments raised.

  241. Link Mauve

    Sorry, 5) again.

  242. dwd

    Link Mauve, That's a very different accusation then asserting that the author has chosen not to agree with, or address, the arguments in the spec.

  243. SamWhited

    dwd, Link Mauve: this is the second time something like this has been brought up recently. I certainly don't think I ignored the arguments, just disagree and addressed why I disagreed, but since obviously multiple people feel that I ignored them I can try to address it on the list again if you want.

  244. jonasw

    dwd, I think if arguments are heard, they should be in a rationale in the XEP, which Styling may or may not have done.

  245. Link Mauve

    dwd, reading both the XEP, the mailing list, and xsf@, I haven’t seen most arguments addressed.

  246. SamWhited

    However, it would be more helpful if I had a list of specific things that you feel were ignored and then I'd be happy to address them (either in the XEP or on list)

  247. jonasw

    (I added a sectino "Design Considerations" to my XEP-0392, which I think is a good way to do that)

  248. Link Mauve

    I think both XEPs should contain a strong rationale about why they are designed that way.

  249. Link Mauve

    SamWhited, I can make such a list, I’ll add that to my TODO list.

  250. Link Mauve

    There were already somewhat-summaries on the mailing list, I’ll use these.

  251. Kev

    jonasw: I think addressing every on-list discussion in a Rationale section's a jolly bad idea, FWIW.

  252. dwd

    Link Mauve, FWIW, I do not wish to set any kind of precedence that every argument raised against a XEP has to be documented in the XEP.

  253. Kev

    Yes, this would be horrendous.

  254. Kev

    Else I want every XEP to document that the protocol isn't pink enough :)

  255. dwd

    Link Mauve, And having raised this argument, but those rules you'd have to document it in every XEP.

  256. jonasw

    sure, but if arguments are brought up multiple times and are well reasoned, I don’t see why not.

  257. jonasw

    I’m fine if people say my arguments aren’t well reasoned, I’d like to know why though :-)

  258. daniel

    message styling actually addressed a lot of critisms. for example we agreed on leaving the keywords in. get rid of the disco feature and so on

  259. Link Mauve

    dwd, indeed, that sounds like a bad idea, but it would be useful to have a short list of alternative approaches and why they weren’t taken.

  260. Link Mauve

    daniel, oh? Did it change since I last read it? I remember it letting the receiving client do whatever it wanted with the rendering.

  261. SamWhited

    I made promises to change it, I didn't want to merge until it was accepted

  262. jonasw

    Link Mauve, the ProtoXEP wasn’t updated, but people agreed to change it

  263. Kev

    Which is the right thing to do, incidentally.

  264. SamWhited

    (unless of course one of those changes is blocking acceptance)

  265. Link Mauve

    Ok.

  266. Kev

    We shouldn't be mandating rendering :)

  267. Link Mauve

    Which confirms my “on list” vote for 4). :)

  268. daniel has left

  269. Kev

    FWIW, I would recommend that if one of these two XEPs are temporarily blocked, both should be :)

  270. Kev

    Because they seem to be a pair of competing proposals that should be considered together.

  271. Link Mauve

    Sounds fair, they both are as of now.

  272. jonasw

    Kev, I personally am not seeing it that way (anymore).

  273. Kev

    (Although this is counter to my desire to get stuff published ASAP so it's under XSFness, so ... yeah)

  274. Kev

    jonasw: You might be in the minority :)

  275. jonasw

    I think both can serve a very useful but distinct purpose each. And I think that we need BMH back.

  276. jonasw

    but I guess that discussion has to wait until next week if not everyone has caught up on the list yet

  277. jere has joined

  278. jonasw

    I proposed to add reconsidering BMH to the agenda for today, not sure if that was seen?

  279. daniel

    so wait just to be clear and that we don't end up dead locking here. Link Mauve you want SamWhited to make those changes before you +1?

  280. Link Mauve

    I would be totally happy with revisiting my vote on BMH with compelling arguments, fyi.

  281. daniel

    because if SamWhited waites until this is approved this will dead lock

  282. Kev

    If already-promised changes are the only thing blocking, I think just taking it on Sam's word that he'll update would be fair. Personally.

  283. Link Mauve

    daniel, no, I haven’t fully caught up with the mailing list, I’m only based on my first reading of his XEP.

  284. Link Mauve

    Of course I wouldn’t block anything due to changes not having been pushed yet.

  285. jcbrand

    Just to be clear concerning the minutes, BMH was a previously proposed protoXEP that wasn't accepted right?

  286. Ge0rG has left

  287. daniel

    jcbrand, yes

  288. Kev

    Yes.

  289. jcbrand

    tx

  290. Link Mauve

    Yes, Flow’s one, about annotating which markup the body is formatted with.

  291. daniel

    https://xmpp.org/extensions/inbox/bmh.html

  292. SamWhited

    Can we hold off on revisiting that one until next week since it just got brought up?

  293. SamWhited

    I haven't had a chance to think about how that would interact with either of the new proposals

  294. Tobias

    sounds sensible

  295. dwd

    (I think, having been rejected, that it would need resubmitting for IPR purposes).

  296. Link Mauve

    Of course, your ProtoXEP changes how it could interact with the ecosystem.

  297. Link Mauve

    (That’s a detail, I’m sure Flow would be happy to do so. :))

  298. jonasw

    SamWhited, to be clear, I’d argue that Styling should get a BMH hint-namespace-thing

  299. daniel

    fwiw i don't think we need bmh for the opt-in approach to message styling that jonasw proposed

  300. Link Mauve

    I haven’t read that part yet, so I’ll abstain for now.

  301. jonasw

    I agree with daniel, but I see merit in the general idea of BMH, following the argument Flow gave when proposing it

  302. daniel has left

  303. jonasw

    but moving this to next week until everybody has had time to consider all the XEPs seems very reasonable to me (not that I’d have any say in that)

  304. Kev

    I think what we actually need is an opt-out, but I need to have time to reply sensibly, and this is team appraisals week.

  305. SamWhited

    I think I agree with what Kev said, but I'm not 100% sure yet about the idea of hints in the styling xep.

  306. daniel

    yeah maybe opt-out is more sensible

  307. Kev

    I think what you want is <this-was-pasted/> for lots of thinsg.

  308. daniel

    i can live with both though

  309. Kev

    And that applies both to styling and to emoticons.

  310. dwd

    Kev, Auto-```?

  311. Link Mauve

    Kev, oh yes, sounds great.

  312. jonasw

    I still think we shouldn’t impose this on clients which don’t want that.

  313. dwd

    jonasw, That would be *terrible*.

  314. SamWhited

    Is this something people feel they need to make decisions on voting right now? If not, can we discuss specific details after the meeting? I want to make sure we get to everything before I need to leave for standup

  315. Link Mauve

    It still breaks existing simple clients, such as bots.

  316. Kev

    Usually when people disagree with me it's because they're clearly idiots, but I think in this discussion there are reasonable arguments on multiple sides.

  317. SamWhited

    Kev: I disagree.

  318. SamWhited

    (sorry, couldn't resist)

  319. Link Mauve

    SamWhited, we can discuss on list/in xsf@.

  320. Kev

    SamWhited: That would be one of the other cases.

  321. Kev

    :p

  322. Link Mauve

    So, 7) AOB?

  323. dwd

    Link Mauve, You don't want to obsolete '146 anymore?

  324. Link Mauve

    dwd, it’s obsolete already.

  325. Link Mauve

    6) was super quick. :)

  326. dwd

    Oh, misread.

  327. dwd

    No AOB from me then.

  328. Tobias

    next meeting?

  329. Link Mauve

    8) Date of next.

  330. Link Mauve

    +1W?

  331. SamWhited

    WFM

  332. Tobias

    wfm

  333. dwd

    WFM2. How many more meetings do we have? Two?

  334. Link Mauve

    Two yes.

  335. Link Mauve bangs gravel.

  336. Link Mauve

    Thanks everyone!

  337. Link Mauve

    Btw, thanks dwd for sending chat states, it really helps to know who is going to speak next.

  338. Link Mauve

    I wish every other council member would do the same.

  339. Tobias

    thanks Link Mauve for running the meeting, thanks jcbrand for the minutes

  340. Tobias

    Link Mauve, my client doesn't support that

  341. SamWhited

    Whew, we survived the styling meeting :) thanks all!

  342. Kev

    SamWhited: Are you *sure*?

  343. dwd

    Link Mauve, Well, here's the thing. Gajim sends them, but doesn't render them.

  344. Link Mauve

    Tobias, I know, you should push for that then, it’s extremely useful during a meeting.

  345. moparisthebest

    so far, I'm still waiting for the xmpp fork of 2017 due to styling

  346. daniel has left

  347. Kev

    Link Mauve: No-one's going to push back on it.

  348. SamWhited

    Mcabber doesn't support anything… but it does do Vim style keybindings, which is really all I want in a client.

  349. dwd

    moparisthebest, You'll *never* be able to read messages again.

  350. Kev

    I've been saying I'd like this for ages, we've just not done it yet.

  351. Link Mauve

    dwd, ah yeah, I provided the patch to send them, I don’t know if any other contributor wants to display them yet.

  352. Link Mauve

    Kev, maybe I could contribute that then. :)

  353. dwd

    Kev, Our new client does, but I'm not using it yet (it's a little simplistic). Probably good enough for MUC meetings, though.

  354. Link Mauve

    As of today I’m now unemployed, I should have more time to fix the world!

  355. daniel has left

  356. Kev

    Link Mauve: If you want to send in a patch for send/render CSI in MUCs, it would be gratefully received (subject to normal patch things).

  357. Link Mauve

    (Of course.)

  358. Ge0rG has left

  359. SamWhited

    Link Mauve: Unemployed, or Funemployed?

  360. jonasw

    (where’s the difference?)

  361. Link Mauve

    SamWhited, heh, doing things for myself, with myself as the drive, and myself as the client. :)

  362. SamWhited

    Nice, I'm jealous

  363. moparisthebest

    dwd, hmm gajim colored your whole message to me red and bolded the whole thing, hence, I have no idea what your intention was

  364. daniel has left

  365. daniel

    i should write a gajim plugin that always randomizes the color in the xhtml variant of the message

  366. Ge0rG

    daniel: randomizes the color of each letter in the message.

  367. Link Mauve

    /load rainbow

  368. daniel

    its called syntax highlighting

  369. daniel

    nouns red, verbs blue, adjectives green and so on

  370. jonasw

    daniel, looking forward to a piece of software which gets this right!

  371. dwd

    jonasw, Stanford released some OSS code to do that in Java a while back.

  372. daniel has left

  373. jcbrand has left

  374. SamWhited

    An extension to replace all messages with the results of <messagebody> | cowsay | lolcat

  375. jonasw

    aww, lolcat doesn’t install

  376. Link Mauve

    __ _ / / (_) | _| | (_) | \_\

  377. Link Mauve

    Hey, just like Yaxim and Conversations display single emoji bigger, poezio could do so with figlet!

  378. daniel has left

  379. jonasw

    figlet fails at utf8.

  380. Link Mauve

    I know. :(

  381. SamWhited

    https://i.imgur.com/mhEqyAK.png

  382. SamWhited

    I can see that working well for all messages in Gajim.

  383. jonasw

    SamWhited, | figlet!

  384. SamWhited

    cowsay and figlet don't play well together

  385. jonasw

    they do

  386. jonasw

    also, that’s kindof the point

  387. SamWhited

    not on my machine; maybe there are options

  388. jonasw

    it looks weird for sure, but it produces sensible output

  389. jonasw

    ah ok, it breaks with long messages

  390. daniel has left

  391. Syndace has left

  392. Syndace has joined

  393. daniel has left

  394. Ge0rG has left

  395. daniel has left

  396. daniel has left

  397. daniel has left

  398. Kev has left

  399. ralphm has left

  400. Ge0rG has left

  401. Ge0rG has left

  402. Ge0rG

    Link Mauve: take the Google NoTo Emoji font and render its SVG into the flickering avatar square

  403. Ge0rG has left

  404. Ge0rG has left

  405. Ge0rG has left

  406. Ge0rG has left

  407. Ge0rG has left

  408. daniel has left

  409. Ge0rG has left

  410. ralphm has joined

  411. daniel has left

  412. Ge0rG has left

  413. Ge0rG has left

  414. Ge0rG has left

  415. Ge0rG has left

  416. ralphm has left

  417. Ge0rG has left

  418. Ge0rG has left

  419. jere has left

  420. jere has joined

  421. Ge0rG has left

  422. Ge0rG has left

  423. SamWhited

    Would anyone be against me making a few slight changes to the styling XEP that don't actually affect anything before it actually gets published? I figured I might as well go ahead and commit some simple editorial changes (typos, definitions, etc.) that I was going to make assuming its accepted (since they're already done, I was only holding off on the larger changes because I didn't want to waste time if it didn't get accepted)

  424. Ge0rG has left

  425. Ge0rG has left

  426. ralphm has joined

  427. Kev has joined

  428. Tobias has joined

  429. Ge0rG has left

  430. jonasw

    SamWhited, editorial changes etc. seem fine to me

  431. Ge0rG has left

  432. SamWhited

    yah, me too, I just want to make sure the people voting don't have any objection

  433. Kev

    SamWhited: Was it accepted?

  434. SamWhited

    Kev: one remaining vote on list

  435. Kev

    If it's not accepted, there's no issue updating the protoXEP. If it's accepted, you don't need Council approval to make changes to an Experimental XEP of which you're the author.

  436. SamWhited

    good point, I guess I could make them anyways.

  437. Kev

    So while *technically* you should publish the version that was approved, I don't think it's going to hurt much.

  438. Ge0rG has left

  439. Ge0rG has left

  440. Kev has left

  441. Ge0rG has left

  442. Ge0rG has left

  443. jonasw

    FWIW, I’ve been holding back editorial changes etc. until after approval too

  444. Ge0rG has left

  445. daniel

    Yeah just update it

  446. moparisthebest

    I haven't heard a single person argue it should be kept as-is so

  447. Ge0rG has left

  448. Ge0rG has left

  449. Ge0rG has left

  450. Ge0rG has left

  451. Kev has joined

  452. Ge0rG has left

  453. Ge0rG has left

  454. Ge0rG has left

  455. Tobias has joined

  456. Ge0rG has left

  457. Ge0rG has left

  458. Ge0rG has left

  459. Ge0rG has left

  460. daniel has left

  461. Ge0rG has left

  462. Ge0rG has left

  463. daniel has left

  464. Ge0rG has left

  465. Ge0rG has left

  466. Kev has left

  467. Ge0rG has left

  468. Ge0rG has left

  469. jere has joined

  470. Ge0rG has left

  471. SamWhited

    I ended up pushing some of the simple non-editorial changes too: https://github.com/xsf/xeps/pull/537

  472. SamWhited

    Still more to do, but that was all the simple stuff that didn't require a lot of work or that I already had done, plus I tried to clear up a few things.

  473. Ge0rG has left