XSF logo XSF Editor Team - 2014-02-26


  1. m&m has left
  2. stpeter has joined
  3. stpeter has left
  4. Steffen Larsen has joined
  5. Steffen Larsen has left
  6. Steffen Larsen has joined
  7. Steffen Larsen has left
  8. Steffen Larsen has joined
  9. Lloyd has joined
  10. Kev I refer to yesterday's BOSH question :)
  11. Steffen Larsen has left
  12. Steffen Larsen has joined
  13. Steffen Larsen has left
  14. Steffen Larsen has joined
  15. Steffen Larsen has left
  16. Ash has joined
  17. m&m has joined
  18. Dave Cridland http://xmpp.org/about-xmpp/xsf/xsf-people/#editor actually says to submit XEPs to Peter directly, still.
  19. m&m hrm
  20. m&m we'll have to get that changed
  21. Dave Cridland I assume I'm meant to send XEPs to editor@xmpp.org?
  22. m&m correct
  23. m&m someone will need to reconcile that and http://xmpp.org/xmpp-protocols/xmpp-extensions/submitting-a-xep/
  24. m&m oh, looks like someone might already have
  25. m&m well, at least left the contact details to the first location
  26. m&m if you already have suggested text, I can put it in place
  27. m&m otherwise the Editorial Team could provide the board something
  28. Dave Cridland Given it already has a statement from a previous Board there, I suppose we should sort it.
  29. Dave Cridland Made a submission in (I think) the correct form. Awaiting Moderator Approval.
  30. m&m has left
  31. m&m has joined
  32. m&m goes to review the queue
  33. Dave Cridland "do you can and will cede rights" - I don't think that's quite right. Beyond the odd phrasing (missing "assert that"?). Our IPR policy is such that we don't ask authors to cede rights, but assign ownership, I think.
  34. m&m that is a good point
  35. m&m I'll correct my template
  36. Dave Cridland (That's WRT the "Thank you for your submission" message I got)
  37. m&m I assumed
  38. Dave Cridland Also my XEP-0001 changes will affect the second sentence; in fact that's not true today either.
  39. Dave Cridland Sorry; will affect if they're accepted.
  40. stpeter has joined
  41. m&m true
  42. m&m so, assuming the proposed update to XEP-0001 is approved, how does the following look? Thank you for your submission. The Approving Body will decide on whether to accept your proposal within the next 14 days. In accordance with the XSF IPR policy, do you: 1. Acknowledge you own the rights to the content in the submitted proposal? 2. Assign those rights to the XMPP Standards Foundation upon acceptance of the proposal? The IPR policy is available at < http://xmpp.org/extensions/ipr-policy.shtml > XEP Editor
  43. Dave Cridland s/will decide/will be polled on/ and you're good.
  44. m&m awesome
  45. m&m I'll add it to our work wiki
  46. Dave Cridland The decision could (by current Council rules, for instance) take 28 days - 14 before Kev polls, and 14 before the timeout is hit.
  47. Dave Cridland I mean, assuming the XEP-0001 changes go in.
  48. Dave Cridland The current XEP-0001 does say 14 days to a decision, but in practise it's 14 days after the next Council meeting.
  49. m&m better to be long than short then
  50. m&m full text once more: Thank you for your submission. The Approving Body will be polled on whether to accept your proposal within the next 28 days. In accordance with the XSF IPR policy, do you: 1. Acknowledge you own the rights to the content in the submitted proposal? 2. Assign those rights to the XMPP Standards Foundation upon acceptance of the proposal? The IPR policy is available at < http://xmpp.org/extensions/ipr-policy.shtml > XEP Editor
  51. Dave Cridland Well, if you say 28 days, you can say "decide". "poll" was my choice of weasel words to stipulate a requirement for the question rather than the answer.
  52. m&m oi
  53. m&m I don't like weaseling through things
  54. Dave Cridland SO the full requirements including both the new XEP-0001 changes proposed and Kev's current rules for Council (which are ruled out of scope for XEP-0001) are that Council members are formally asked for objections within 14 days, and must respond with objections either in a meeting or on the standards list within (a further) 14 days - otherwise they are deemed to have no objection.
  55. Kev And assuming there are meetings within the next 14 days.
  56. Kev e.g. this isn't necessarily true over Christmas or such if we skip two meetings.
  57. Dave Cridland What made it complicated to explain in XEP-0001 is that the second 14-day period (starting when the Council members are asked), is regulated by Kev as Council Chair, and not by XEP-0001.
  58. Dave Cridland Kev, Ah, which? The objection timeout of the poll timeout? If we need exceptions for the poll timeout that means I need to tweak that text.
  59. Kev I would be inclined to keep the current text, almost.
  60. Kev But to instead of say 'decide' say 'Council will start an objection period within...' or such.
  61. Kev Wordsmithing without the current text in front of me's probably a bad idea.
  62. Kev But that's the intention, as I see it.
  63. Kev Council will start a voting period on their next meeting, usually, or the one after that if it's submitting close to the line.
  64. Kev Then that will last however long current Council procedures are for it to take.
  65. Kev I think that as long as xep1 isn't misleading, it doesn't need to tie us down completely.
  66. Kev (That is - a reading author should not be misled as to how long it'll take)
  67. Dave Cridland Kev, Right. My changes to XEP-0001 are exactly that, modulo that it requires a poll to be made (though not a meeting as such) within 14 days.
  68. Kev I only read the summary - only just back after being out all afternoon. Will read the changes proper at some point.
  69. Dave Cridland Kev, Whereas the old one required any objections be logged within 14 days, which isn't - quite - how you work.
  70. Kev It certainly gave that impression. You know my alternative interpretation, but I agree that reading it one would expect an answer within 14 days (or next meeting).
  71. Dave Cridland Yes; as I say I'm more concerned with changing XEP-0001 to reflect reality than insisting you guys change.
  72. Lloyd was it buddycloud#owner ?
  73. Lloyd window fail, sorry.
  74. m&m hrm
  75. stpeter heh
  76. m&m http://jabber.org/protocol/muc no longer redirects somewhere useful
  77. stpeter it would not surprise me if we lost all the redirects in a webserver change at some point
  78. m&m that looks to be the case
  79. m&m before it was Apache httpd? Now it's nginx
  80. stpeter it was lighttpd for quite a while
  81. m&m ah that's right
  82. stpeter surely Apache in the ancient days
  83. m&m in any case, redirects are server specific, so any change would very likely cause losss
  84. Lloyd has left
  85. m&m has left
  86. m&m has joined
  87. Dave Cridland Thanks for processing that submission. Sorry it was such a pain. :-)
  88. m&m we're working out the kinks (-:
  89. stpeter :)
  90. stpeter process improvements have occurred already!
  91. m&m I'm tempted to write a Makefile to deal with various pieces
  92. m&m see if we can do it without someone actually being *on* the webserver all the time
  93. stpeter nod
  94. Kev Presumably you could do everything with a git hook if you wanted.
  95. Kev Only push to master stuff you want published, etc.
  96. m&m possibly
  97. Kev With my infrastructure hat on, I would rather we didn't have many people trying to do things with shell on the machine.
  98. m&m well, maybe not
  99. m&m I completely understand
  100. m&m I'll have to think about how we could use git pushes to do this
  101. Kev I'll give out shell to everyone if we need to.
  102. Kev If we can avoid it, I'd find it preferable.
  103. m&m the differences in some cases are very subtle
  104. m&m /nod
  105. Neustradamus has left
  106. Neustradamus has joined
  107. Neustradamus has left
  108. Neustradamus has left
  109. Neustradamus has left
  110. Neustradamus has joined
  111. Ash has left
  112. Dave Cridland has joined
  113. stpeter has left
  114. stpeter has joined