XSF Editor Team - 2014-02-26

I refer to yesterday's BOSH question :)

http://xmpp.org/about-xmpp/xsf/xsf-people/#editor actually says to submit XEPs to Peter directly, still.

hrm

we'll have to get that changed

I assume I'm meant to send XEPs to editor@xmpp.org?

correct

someone will need to reconcile that and http://xmpp.org/xmpp-protocols/xmpp-extensions/submitting-a-xep/

oh, looks like someone might already have

well, at least left the contact details to the first location

if you already have suggested text, I can put it in place

otherwise the Editorial Team could provide the board something

Given it already has a statement from a previous Board there, I suppose we should sort it.

Made a submission in (I think) the correct form. Awaiting Moderator Approval.

"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.

that is a good point

I'll correct my template

(That's WRT the "Thank you for your submission" message I got)

I assumed

Also my XEP-0001 changes will affect the second sentence; in fact that's not true today either.

Sorry; will affect if they're accepted.

true

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

s/will decide/will be polled on/ and you're good.

awesome

I'll add it to our work wiki

The decision could (by current Council rules, for instance) take 28 days - 14 before Kev polls, and 14 before the timeout is hit.

I mean, assuming the XEP-0001 changes go in.

The current XEP-0001 does say 14 days to a decision, but in practise it's 14 days after the next Council meeting.

better to be long than short then

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

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.

oi

I don't like weaseling through things

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.

And assuming there are meetings within the next 14 days.

e.g. this isn't necessarily true over Christmas or such if we skip two meetings.

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.

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.

I would be inclined to keep the current text, almost.

But to instead of say 'decide' say 'Council will start an objection period within...' or such.

Wordsmithing without the current text in front of me's probably a bad idea.

But that's the intention, as I see it.

Council will start a voting period on their next meeting, usually, or the one after that if it's submitting close to the line.

Then that will last however long current Council procedures are for it to take.

I think that as long as xep1 isn't misleading, it doesn't need to tie us down completely.

(That is - a reading author should not be misled as to how long it'll take)

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.

I only read the summary - only just back after being out all afternoon. Will read the changes proper at some point.

Kev, Whereas the old one required any objections be logged within 14 days, which isn't - quite - how you work.

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).

Yes; as I say I'm more concerned with changing XEP-0001 to reflect reality than insisting you guys change.

was it buddycloud#owner ?

window fail, sorry.

hrm

heh

http://jabber.org/protocol/muc no longer redirects somewhere useful

it would not surprise me if we lost all the redirects in a webserver change at some point

that looks to be the case

before it was Apache httpd? Now it's nginx

it was lighttpd for quite a while

ah that's right

surely Apache in the ancient days

in any case, redirects are server specific, so any change would very likely cause losss

Thanks for processing that submission. Sorry it was such a pain. :-)

we're working out the kinks (-:

:)

process improvements have occurred already!

I'm tempted to write a Makefile to deal with various pieces

see if we can do it without someone actually being *on* the webserver all the time

nod

Presumably you could do everything with a git hook if you wanted.

Only push to master stuff you want published, etc.

possibly

With my infrastructure hat on, I would rather we didn't have many people trying to do things with shell on the machine.

well, maybe not

I completely understand

I'll have to think about how we could use git pushes to do this

I'll give out shell to everyone if we need to.

If we can avoid it, I'd find it preferable.

the differences in some cases are very subtle

/nod