XMPP Council - 2019-02-06


  1. Tokodomo has joined
  2. Tokodomo has left
  3. Remko has joined
  4. labdsf has left
  5. labdsf has joined
  6. Remko has left
  7. Zash has left
  8. labdsf has left
  9. labdsf has joined
  10. dwd has left
  11. Remko has joined
  12. Remko has left
  13. dwd has left
  14. Tobias has joined
  15. dwd has left
  16. Remko has joined
  17. grumpy has left
  18. Remko has left
  19. lnj has joined
  20. SouL has left
  21. lnj has left
  22. labdsf has left
  23. Remko has joined
  24. lnj has joined
  25. Remko has left
  26. Tobias has joined
  27. Tobias has left
  28. labdsf has joined
  29. Tobias has left
  30. labdsf has left
  31. labdsf has joined
  32. Remko has joined
  33. Remko has left
  34. Remko has joined
  35. Guus has left
  36. lnj has left
  37. lnj has left
  38. lnj has left
  39. lnj has left
  40. lnj has left
  41. lnj has left
  42. lnj has left
  43. lnj has left
  44. lnj has left
  45. lnj has left
  46. lnj has left
  47. lnj has left
  48. lnj has left
  49. lnj has left
  50. lnj has left
  51. lnj has left
  52. lnj has left
  53. lnj has left
  54. lnj has left
  55. lnj has left
  56. lnj has left
  57. lnj has left
  58. lnj has left
  59. lnj has left
  60. lnj has left
  61. lnj has left
  62. lnj has left
  63. lnj has left
  64. Zash has joined
  65. lnj has left
  66. lnj has left
  67. lnj has left
  68. lnj has left
  69. lnj has left
  70. lnj has left
  71. lnj has left
  72. lnj has left
  73. lnj has left
  74. lnj has left
  75. lnj has left
  76. lnj has left
  77. lnj has left
  78. lnj has left
  79. lnj has left
  80. lnj has left
  81. lnj has left
  82. lnj has left
  83. lnj has left
  84. lnj has left
  85. lnj has left
  86. lnj has left
  87. lnj has left
  88. lnj has left
  89. lnj has left
  90. lnj has left
  91. lnj has left
  92. lnj has left
  93. lnj has left
  94. lnj has left
  95. lnj has left
  96. lnj has left
  97. lnj has left
  98. lnj has left
  99. lnj has left
  100. lnj has left
  101. lnj has left
  102. lnj has left
  103. lnj has left
  104. lnj has left
  105. lnj has left
  106. lnj has left
  107. lnj has left
  108. lnj has left
  109. lnj has left
  110. lnj has left
  111. lnj has left
  112. lnj has left
  113. lnj has left
  114. lnj has left
  115. lnj has left
  116. lnj has left
  117. lnj has left
  118. lnj has left
  119. lnj has left
  120. lnj has left
  121. lnj has left
  122. lnj has left
  123. lnj has left
  124. lnj has left
  125. lnj has left
  126. lnj has left
  127. lnj has left
  128. lnj has left
  129. lnj has left
  130. pep. has joined
  131. lnj has left
  132. labdsf has left
  133. labdsf has joined
  134. dwd has left
  135. Tobias has joined
  136. Tobias has joined
  137. Tobias has left
  138. Tobias has left
  139. Tobias has left
  140. Tobias has left
  141. labdsf has left
  142. labdsf has joined
  143. Tokodomo has joined
  144. grumpy has joined
  145. grumpy has joined
  146. Kev Should be back in time for 4. Today's getting away from me, so sorry if I'm not.
  147. Guus has joined
  148. Guus has joined
  149. Guus has joined
  150. Guus has joined
  151. Guus has joined
  152. Ge0rG has joined
  153. Ge0rG dwd: https://github.com/xsf/xeps/pull/739 was merged, so it's technically a pre-advancement thing and not something to vote on. However, it's an indication of what changed in the XEP since it was last read by Council, so it might be good background info
  154. Ge0rG https://github.com/xsf/xeps/pull/752 is actually a submarine to make 0045 better.
  155. Ge0rG I hope that I'll be available in time for the Meeting, because my client scheduled a meeting at "around" 15:30
  156. Ge0rG So please excuse me if I'm late, and feel free to put "my" Agenda items to the end of the list
  157. zinid has joined
  158. Ge0rG He's not here yet, so I *am* going to be late.
  159. debacle has joined
  160. jonas’ :(
  161. Ge0rG Maybe he'll be so late that we can have Meeting before. But somehow I have doubts about that.
  162. Ge0rG If you don't read anything from me, it's either xmpp.org connectivity or I'm AFK-busy.
  163. jonas’ good luck
  164. Kev Been for a jog. Dripping. Can't sit like this, might be 2mins late.
  165. ralphm TMI
  166. dwd 1) Wrap Call [healthier]
  167. dwd Who's here?
  168. jonas’ I am
  169. Link Mauve o/
  170. dwd Kev's in the shower and will be doing the meeting wearing only a towel. Keep a hold of that image.
  171. dwd And Ge0rG has been swallowed by a meeting, I think.
  172. jonas’ thank you very much, dwd.
  173. dwd jonas’, I'd say it's my pleasure, but really, it's not.
  174. Kev I'm here.
  175. intosi has joined
  176. Kev Don't worry, I don't have a towel.
  177. jonas’ that doesn’t improve anything, Ke.
  178. jonas’ that doesn’t improve anything, Kev.
  179. ralphm I'm here for PR 744
  180. zinid here for XOR
  181. dwd fetches the mind-bleach.
  182. jonas’ oookay, maybe let’s get on with the agenda.
  183. dwd 2) Agenda bashing
  184. dwd Thanks to jonas’ I think we caught everything.
  185. dwd Though Ge0rG said #739 wasn't really Council and had been merged (good).
  186. dwd So moving on:
  187. dwd 3) Items for voting:
  188. dwd a) #739: XEP-0410: pre-LC and LC feedback https://github.com/xsf/xeps/pull/739
  189. dwd (Merged as noted)
  190. Kev (To save time, I'm going to be on-list on pretty much everything, sorry)
  191. dwd b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752
  192. jonas’ postpone until Ge0rG is maybe there, dwd?
  193. dwd I'm fine with doing things a bit out of order in case Ge0rG manages to make it, yes. So parking this.
  194. jonas’ same for c) then
  195. dwd d) #745: XEP-0234: Use <hash-used/> to signify the hash function being used, instead of an (invalid) empty <hash/> https://github.com/xsf/xeps/pull/745
  196. Link Mauve So, for this one I have a big set of changes stacked in a branch somewhere.
  197. Link Mauve I’d like to avoid bumping the namespace before merging those.
  198. dwd Link Mauve, Meaning what?
  199. Link Mauve As in, what is the content of these changes?
  200. jonas’ Link Mauve, to be honest, I’ve been waiting for your changes for over a year now
  201. Link Mauve Yeah, and I for more than that.
  202. dwd Link Mauve, Meaning you want us to delay this?
  203. Link Mauve The addition of <hash-used/> was already a breaking change without a namespace bump, so we can probably do so once more, and then bump once I’m ready for pushing mine.
  204. Link Mauve dwd, or that yes.
  205. jonas’ I don’t have a strong opinion either way.
  206. jonas’ the :2 version is "broken" anyways due to what Link Mauve said.
  207. Link Mauve :5*
  208. dwd I think this does need a namespace bump. And I'm not happy about delaying it for PRs we don't have, sorry.
  209. ralphm release early, release often?
  210. jonas’ the ~:2 (that’s hashes, not ft)~ :5 version is "broken" anyways due to what Link Mauve said.
  211. jonas’ dwd, NS-bumping Jingle-FT is meh though
  212. dwd jonas’, What do you mean?
  213. jonas’ (NS-bumping *anything* is, but file transfer is particularly frustrating when it fails in non-obvious ways)
  214. jonas’ Link Mauve, how realistic is it that you get your changes in order ’til next meeting?
  215. Link Mauve dwd, it’s used in quite a lot of places already, has many implementations, bumping the namespace temporarily sounds indeed meh.
  216. Link Mauve jonas’, I’ll put that as a high priority, so somewhat likely.
  217. dwd You may have a point, actually - the hash -> hash-used change means that an application expecting hash simply sees no hash at all.
  218. dwd Which is allowed by the spec. So I can live without the namespace change on that basis.
  219. dwd Anyway votes:
  220. dwd Kev, assuming on-list.
  221. jonas’ I’m +1 on this without namespace change
  222. jonas’ (-1 with namespace change)
  223. Kev Yes, on-list please.
  224. dwd I'm +1, I think.
  225. dwd Link Mauve, ?
  226. Link Mauve I’m +1 without namespace change.
  227. dwd OK.
  228. dwd e) Adopt Proposed XMPP Extension: XMPP Over RELOAD (XOR) Abstract: This specification defines an XMPP Usage of REsource LOcation And Discovery (RELOAD). The XMPP usage provides an ability for XMPP clients to discover other peers' location through the peer-to-peer overlay. Once a peer location is determined, the RELOAD AppAttach method is used to establish a direct connection between peers through which XMPP streams are exchanged. https://xmpp.org/extensions/inbox/xor.html
  229. jonas’ I have no knowledge about RELOAD.
  230. Ge0rG .o/
  231. Neustradamus has joined
  232. jonas’ Ge0rG, wb
  233. dwd I'm +1 on this. (I don't know more about RELOAD than the abstract of the RFC says, but it seems believable)
  234. jonas’ I’d also like to mention that the XEP contains stuff which definitely does not belong into standards track
  235. Link Mauve I skimmed through it, read what zinid said about this protocol a while ago on conversations@ and am +1 on the basis that it looks good and sounds like an interesting proposal.
  236. dwd Ge0rG, To save you skimming back, we've shuffled the order form the agenda to put the '410 stuff at the end.,
  237. jonas’ specifically, in §8.2: > The root certificate of the overlay MUST be created by the XSF. All intermediate authority's certificates MUST be signed by this root certficate.
  238. jonas’ I don’t think we can accept this without Board involvement.
  239. Link Mauve But I don’t know much about RELOAD itself.
  240. Ge0rG jonas’: not even as Experimental?
  241. jonas’ Ge0rG, not even as experimental
  242. dwd jonas’, It's Experimental, in fairness, but yes, it might need splitting for that basis.
  243. zinid if only I knew in what I should split it
  244. jonas’ ralphm, if you happen to be around, a quick suggestion on this?
  245. ralphm Yeah, I'm thinking
  246. jonas’ zinid, anything where it says "the XSF has to" needs to be removed, I think
  247. zinid where is the pattern for writing proposals for Board?
  248. Ge0rG I think that a wire format for exchanging CSRs and CRTs between XMPP entities, based on the entity JIDs, would be a welcome addition and solve the *technical* issue.
  249. jonas’ zinid, same format, but different track. it needs to be different documents.
  250. ralphm I think it is kind of weird to have the XSF as the only entity to set up something like this.
  251. dwd zinid, Could you note that it requires a single CA, and then create a distinct XEP you define an XSF-based CA?
  252. jonas’ (i.e. you switch "Standards TRack" to "Procedural" or something and describe how the CA should operate)
  253. zinid jonas’, I can of course remove that from the protoxep, easily, but that doesn't solve the problem
  254. jonas’ zinid, what dwd says is correct and sensible.
  255. Ge0rG why XSF-based at all? It can be completely external as long as somebody documents it as the trust root for RELOAD-XMPP
  256. dwd zinid, The problem is that it requires a single CA? Or simply signed certificates?
  257. zinid dwd, only signed
  258. zinid by trusted CA
  259. ralphm I.e. the greater XMPP network is not a thing that is, or should be, controlled by the XSF?
  260. dwd zinid, Right. So the practical problem is that nobody signs end-user EE certs for jids?
  261. zinid dwd, yes
  262. zinid also, "trusted" in the sense that the CA should not produce massive amount certificates for attackers
  263. zinid *of certificates
  264. zinid that's the only requirement
  265. dwd zinid, OK. On that basis, I think it'd be best to note that requirement, and then remove the XSF-CA part (and if you want, submit that as a different protoXEP for the Board to consider).
  266. zinid okay for me
  267. jonas’ zinid, I understand that certificates are needed here. Could you replace 8.1 and 8.2 with something more generic, leaving the XSF out of that, and make a follow-up document where you describe what’s necessary, on a procedural level, to make this work securely?
  268. jonas’ ah, yes that
  269. zinid jonas’, yes, I will
  270. jonas’ excellent
  271. zinid so reject it, will be ready to the next meeting
  272. jonas’ zinid, fine by me
  273. dwd zinid, Sounds good. In that case I'll -1 this on the expectation that a new submission will pass.
  274. jonas’ I’m -1 on the basis that the presented ProtoXEP has Procedural content which needs to be acked by Board.
  275. zinid (probably you will have some time for RELOAD itself, it's very good RFC :) )
  276. Link Mauve Yup, -1 waiting for the next version. :)
  277. jonas’ so that’s sorted
  278. ralphm jonas’: I don't agree this is a requirement for rejecting it as experimental.
  279. ralphm I do agree that Board should be involved if we need to setup a CA.
  280. dwd I'd rather the Board chose whetheror not to adopt an XSF-CA document.
  281. jonas’ I agree with dwd.
  282. dwd f) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft https://github.com/xsf/xeps/pull/744
  283. ralphm dwd: I agree with that of course
  284. Ge0rG I'm pretty sure the XSF doesn't want to participate in the CA ~racket~ business.
  285. Link Mauve dwd, +1, but IIRC we already agreed on this change a few weeks ago.
  286. ralphm dwd: I'm not sure if adopting it as experimental means we're going to do it, though.
  287. Link Mauve I’m fine with the wording of it.
  288. ralphm On 744, I understand that Kev had issues with it
  289. jonas’ +1 on #744
  290. Kev Let me remind myself.
  291. ralphm Go ahead
  292. Ge0rG +1 on #744
  293. Kev Oh, yes, so this means that someone can automatically take authorship of a spec by proposing it.
  294. Ge0rG Oh. good point.
  295. dwd +0 on this. I think in practise it doesn't matter, but the authorship change is curious.
  296. jonas’ oh, I totally missed that part of the sentence O_O
  297. Kev I think that's wrong, and asking for it to be advanced, and changing authorship, should be independent things.
  298. Ge0rG But how else do we want to handle it?
  299. jonas’ I hate reading diffs
  300. jonas’ I agree with Kev
  301. dwd Ge0rG, Anyone can ask for a Deferred doc to be advanced seems fine.
  302. Ge0rG Do we want to accept Proposal from anybody?
  303. Ge0rG dwd: even without an author?
  304. jonas’ Ge0rG, no, we still vote on it
  305. jonas’ Ge0rG, yes, if a XEP is ready for Draft, it doesn’t matter if the author is still around
  306. dwd Ge0rG, We do, under this PR. It's just that this PR *also* magics the proposer into a XEP Author.
  307. jonas’ afterwards, the Council will be the gatekeeper for changes anyways
  308. Ge0rG I kind-of-like that you can't Propose without commiting to maintain it.
  309. jonas’ yeah, I don’t like that authorship change, I think it’s unnecessary
  310. Kev dwd: And the way I read it, also bumping off the old Author.
  311. dwd I am strictly ambivalent to it.
  312. Kev Or, at least, it's not clear that it /doesn't/ mean that.
  313. ralphm Kev: my thinking was that accepting changing ownership would be up to the Editor
  314. Ge0rG -1 as it is +1 with <del>, thereby taking up the role of XEP author</del>
  315. Tokodomo has joined
  316. dwd Kev, I don';t think we explicitly have to kill them.
  317. Kev ralphm: I don't think that's what this text says.
  318. peter has joined
  319. jonas’ -1 as it is +1 with <del>, thereby taking up the role of XEP author</del>
  320. ralphm I am not saying it changes the Author, it takes up the role for the purpose of moving it in the process as further described.
  321. jonas’ if the Approving Body (AB) decides that a specification should have an active author to advance, they can still require that and make the proposer author, if needed.
  322. dwd ralphm, That's definitely not what it says.
  323. ralphm If that's not clear (or you think that's actually not different), that was at least my attempt.
  324. jonas’ ralphm, oooh, I see the intent now
  325. jonas’ maybe ", thereby taking up the role of the XEP author for the purpose of proposing"?
  326. Kev I think just removing ", thereby taking up the role of XEP author" is easiest.
  327. dwd Right, I think the objections are clear.
  328. Ge0rG ralphm: what responsibilities does an author have for the purpose of moving a XEP in the process?
  329. ralphm The problem is that you need an XEP Author to process LC feedback
  330. dwd Note that, as a point of order, we don't get a binding vote on this as Council since the Approving Body is Board.
  331. dwd ralphm, Oh, that is actually a good point.
  332. Kev ralphm: Sure, but Council can look at getting a new Author where needed.
  333. jonas’ ralphm, indeed a good point
  334. Kev And Deferred and Abandoned are not equivalent.
  335. Ge0rG Council can also (theoretically) incorporate LC feedback.
  336. dwd Kev, Right, but ralphm's suggestion mean that if you propose a Deferred XEP, you are taking responsibility for it.
  337. jonas’ ralphm, can you put some wording together which makes this clear? making the proposer responsible for processing (at least by making concrete proposals for) the LC feedback would be good, methinks
  338. Ge0rG But I think it makes sense to put that burden on the Proposer.
  339. ralphm dwd: but only if there's no active Author to collaborate with.
  340. jonas’ this is, by default, limited to processing the LC feedback, in my mind.
  341. Kev dwd: Yes - but I think automatically making someone Author is the wrong thing.
  342. jonas’ I think thath makes a lot of sense
  343. jonas’ I think that line of thinking ("Proposer manages LC feedback if author(s) are unavailable") makes a lot of sense
  344. jonas’ I think that line of thinking ("Proposer manages LC feedback (and only that if no other agreements with the AB exist about that) if author(s) are unavailable") makes a lot of sense
  345. ralphm And indeed, my intent was that in case of abandonment, somebody proposing to move further would be interested in taking up ownership.
  346. dwd Or simply that the Proposer may be required to take the role of Author during Last Call.
  347. ralphm If proposer is allowed to process LC feedback, why doesn't that make him an author of sorts?
  348. Kev I think we're at the stage of some new text being a good idea, and may as well move on.
  349. Ge0rG dwd: and after Last Call, until all feedback is incorporated
  350. Ge0rG We are also overdue with our time and underdue with our Agenda.
  351. dwd ralphm, Do you have enough feedback from us to clarify the text?
  352. peter This sounds a bit like the Document Shepherd role at the IETF.
  353. dwd Ge0rG, Indeed.
  354. dwd peter, That also.
  355. ralphm dwd: I don't know yet how to process the feedback into new text
  356. Kev ralphm: largely because I forsee that someone is going to go through every deferred XEP, propose it for advancement, and get their name at the top of it automatically because of it.
  357. ralphm peter: I'm not familiar with that concept
  358. jonas’ maybe take the details to the list?
  359. dwd ralphm, OK - but I'm going to move on, because I think we're just getting bogged down in detail.
  360. dwd g) #746: XEP-0060: Add missing @publisher in pubsub schema https://github.com/xsf/xeps/pull/746
  361. ralphm Kev: but if somebody who has abandoned authorship isn't involved, but the document changes anyway, isn't that a problem, too?
  362. Link Mauve g) I’m obviously +1, as I am its author.
  363. dwd I'm +1 on '746, this looks satrightforward.
  364. peter ralphm: https://www.ietf.org/blog/iesg-statement-document-shepherds/
  365. jonas’ +1
  366. dwd ralphm, peter - sorry, we've moved on.
  367. peter yep
  368. ralphm dwd: I'd still like to somehow discuss details with council
  369. peter that's why I prefaced with `ralpphm:` :P
  370. Ge0rG +1
  371. peter goes back to $dayjob
  372. ralphm peter: thanks!
  373. dwd h) #747: XEP-0084: Bump the maximum of @width and @height to 65535 https://github.com/xsf/xeps/pull/747
  374. Link Mauve +1 too, for the same reason.
  375. Ge0rG This is a schema change, technically it requires a namespace bump.
  376. jonas’ +1, it doesn’t change any normative part, and is probably an oversight of <revision> <version>0.11</version> <date>2007-07-25</date> <initials>psa</initials> <remark><p>Removed image size requirements.</p></remark> </revision>
  377. Link Mauve Ge0rG, uh, why?
  378. dwd I'm going to have to be on-list for this one. I'm going to have to dig a little.
  379. dwd Mostly on the question of whether Ge0rG is right or not.
  380. Link Mauve Do we have any mention that schemas are normative that way?
  381. Ge0rG Link Mauve, jonas’: if you followed the old schema and implemented it as u8, you'll end up overflowing your data field
  382. Kev Schemas are non-normative in XEPs.
  383. dwd We have usually held within the XSF that schemas are non-normative.
  384. jonas’ Ge0rG, if you parse XML strictly by schema without validating it, you’re doing it wrong
  385. Link Mauve Kev, that’s what I remember too.
  386. Link Mauve jonas’, and if you do validate it, as it is you will reject way too many otherwise valid images.
  387. Ge0rG I'm not saying I'm -1, just interpreting the consequences of the change.
  388. dwd Ge0rG, Are you -1 as-is, or not, then?
  389. jonas’ (please don’t namespace-bump avatars...)
  390. Ge0rG dwd: +1 because I want to see the world burn
  391. dwd :-)
  392. jonas’ 🔥
  393. dwd Looping back to the beginning, then.
  394. Ge0rG Also Link Mauve owes me a no-namespace-bump XEP change then :D
  395. dwd b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752
  396. Ge0rG the background of #752 was a list discussion, of which I concluded that it would be great to have an application-specific <not-an-occupant/> or maybe <not-in-room/> condition in MUC
  397. jonas’ +1 on this, or any other of the commonly-encountered RFC 6120 stanza error condition for accompanying not-an-occupant
  398. dwd Is there any reason why this isn't using the `@by` attribute of the error element?
  399. Ge0rG But I didn't want to PR MUC yet.
  400. Ge0rG But really I want this new condition added to 0045.
  401. jonas’ dwd, that’s a good addition actually
  402. Ge0rG dwd: you mean the example?
  403. Link Mauve Is there any reason this isn’t part of 0045 instead?
  404. Ge0rG Link Mauve: namespace-bumping-MUC
  405. Zash The entire thing?!
  406. jonas’ dwd, but having a distinct muc-specific <not-an-occupant/> in addition is a good thing
  407. Ge0rG Zash: all of it
  408. dwd Ge0rG, So do it a MUC extension that adds it under a different namespace?
  409. jonas’ urn:xmpp:muc:1!
  410. Ge0rG dwd: why not have a feature for it on MUC and use the MUC namespace?
  411. dwd Ge0rG, <feature var="urn:xmpp:muc:errors:0"/><!-- sends application-specific errors for MUC -->
  412. Ge0rG Ah, and use that NS.
  413. dwd Ge0rG, Using another XEP's namespace doesn't really sit well with me.
  414. Link Mauve A feature sounds like the way forward.
  415. Ge0rG dwd, Link Mauve: the specific reason for having this in 0410 was because I wanted to have this discussion, but didn't want to further delay 0410
  416. dwd I agree this is useful (though also, @by needs more implementation and use), but it's useful and generic.
  417. Link Mauve +1
  418. debacle has left
  419. Ge0rG if we add <not-an-occupant xmlns="urn:xmpp:muc:errors:0"/> into 0410, we are now defining MUC errors in a XEP that's actually doing something different.
  420. dwd So, I think overall this is a -1 from me, sorry. That said, I don't think this needs to mean '410 needs delaying.
  421. Ge0rG What about jonas’ writing a separate Application Specific Errors for MUC XEP?
  422. jonas’ why me
  423. Ge0rG jonas’: you brought that mess upon me.
  424. jonas’ dammit
  425. Ge0rG I add a @by into 0410, and we publish it.
  426. jonas’ I don’t have a weekend this week, so I can’t promise anything
  427. Ge0rG is anybody against having @by in 0410?
  428. jonas’ @by is a good thing here
  429. dwd Ge0rG, jonas’ - votes?
  430. jonas’ I’m +0
  431. Ge0rG and I'm -1 on #752, despite being the author
  432. jonas’ ha
  433. Ge0rG because it needs its own XEP.
  434. Link Mauve ^^
  435. dwd Awesome.
  436. Ge0rG Thank you for the discussion, everyone.
  437. dwd Great when people reject their own stuff. :-)
  438. dwd c) Advance XEP-0410 to Draft https://xmpp.org/extensions/xep-0410.html
  439. Ge0rG The main part of the PR was this: > Please have a Council discussion.
  440. Ge0rG +1 to advance 0410 (with a @by added into the error)
  441. dwd Same for me - +1 (with @by)
  442. jonas’ +1 to advance 410, with @by added
  443. Link Mauve Same here, +1.
  444. Ge0rG jonas’: shall I make a PR or will you do it with your Editor Hat on?
  445. jonas’ Ge0rG, please make a PR
  446. dwd OK. I think we're done with items for voting.
  447. jonas’ Ge0rG, I like to have more eyes (even if it’s just four) on it before merging stuff
  448. dwd 4) Outstanding Votes
  449. dwd If anyone has anything, please do so on list given the overrun.
  450. dwd 5) Next Meeting
  451. dwd Same time next week?
  452. jonas’ +1w is ok for me
  453. Link Mauve Same.
  454. dwd 6) AOB
  455. dwd (Please no)
  456. jonas’ Thanks to Tedd Sterr for doing the minutes all the time and the vote summaries.
  457. Ge0rG +1 to that
  458. dwd Yes, that is amazingly helpful.
  459. jonas’ tremendously helpful in both of my roles here
  460. Ge0rG I have a proto-proto-XEP about Simple Encryption for XMPP in the works, but I don't dare Ask Council.
  461. dwd It'd be great if they joined as a member, though that'd involve a real name.
  462. Kev Indeed, yay to minutes etc.
  463. dwd Assuming no other business...
  464. dwd 7) Ite, Meeting Est
  465. Kev I have a non-AOB AOB.
  466. Kev Please let's keep to 30mins.
  467. dwd Kev, I generally agree. But we had 7 items to vote on, and I infinitely prefer voting in-meeting to voting on-list where possible.
  468. jonas’ dwd, we could’ve moved the remaining items to +1w
  469. Kev Quite.
  470. jonas’ I don’t want to cut down on in-meeting discussions, I think those are valuable
  471. dwd Sure, but I think the first meeting after Summit is always going to be busy - lots of energy, plus a missed meeting the week before.
  472. Ge0rG jonas’: https://github.com/xsf/xeps/pull/754
  473. dwd So, you know, sorry-not-sorry. :-)
  474. Kev I think the likely outcome is the opposite of the desired one if it becomes a habit.
  475. Kev Which is all votes going to onlist.
  476. Ge0rG Kev: all votes or just the ones cast after the first 30 minutes? ;-)
  477. Kev Once upon a time Council meetings were a mess, usually ran over, stuff was invariably onlist.
  478. Kev We eventually sorted that out and got down to sensible 30 minute meetings, with most stuff happening during them.
  479. Kev I'm keen not to go back.
  480. Kev And I'd rather punt items to the following week than have people sitting appearing to be in the meetings but actually not because they're doing something else once the meeting overruns.
  481. Ge0rG I'm really sorry for being late.
  482. Kev Stuff happens.
  483. Kev I was late too.
  484. Kev I don't think either were what caused the running over.
  485. ralphm waves
  486. Guus has joined
  487. zinid has left
  488. labdsf has left
  489. pep. has joined
  490. Tokodomo has left
  491. Tokodomo has joined
  492. Tokodomo has left
  493. Tobias has joined
  494. intosi has left
  495. intosi has joined
  496. labdsf has joined
  497. debacle has joined
  498. Tobias has left
  499. Guus has left
  500. ivucica has left
  501. ivucica has joined
  502. Zash has left
  503. grumpy has joined
  504. Guus has joined
  505. debacle has left
  506. labdsf has left
  507. labdsf has joined
  508. dwd has left
  509. labdsf has left
  510. labdsf has joined
  511. Tokodomo has joined
  512. Link Mauve has joined
  513. Tokodomo has left
  514. Link Mauve has joined
  515. Zash has left
  516. labdsf has left
  517. labdsf has joined
  518. peter has left
  519. lnj has left
  520. lnj has left
  521. lnj has joined
  522. lnj has left
  523. lnj has left
  524. lnj has joined
  525. Guus has left
  526. Guus has joined
  527. Guus has left
  528. Tokodomo has joined
  529. Guus has joined
  530. lnj has left
  531. lnj has left
  532. lnj has joined
  533. Link Mauve has left
  534. peter has joined
  535. Guus has left
  536. Tokodomo has left
  537. Guus has joined
  538. Remko has left
  539. Link Mauve has joined
  540. grumpy has left
  541. Guus has left
  542. Guus has joined
  543. grumpy has joined
  544. Guus has left
  545. oli has joined
  546. Tobias has joined
  547. Zash has left
  548. Guus has joined
  549. Link Mauve has joined
  550. pep. has joined
  551. Link Mauve has joined
  552. SouL has left
  553. zinid has left
  554. peter has left
  555. oli has joined
  556. lnj has left
  557. lnj has left
  558. lnj has left
  559. pep. > dwd> It'd be great if they joined as a member, though that'd involve a real name. Would it? There's no reaction on the LC for 345. I am the only one to have replied to it?
  560. lnj has joined
  561. Link Mauve has joined