On 30 Sep 2021, at 09:56, Dave Cridland wrote:
>
> All,
>
> Kev Smith noted that we have been a bit weird about handling updates to XEPs
> from authors during the Proposal phase (that is, Proposed state, from Last
> Call through to completion of a vote to Stable).
Ta.
> 1) When can authors update XEPs?
>
> XEP-0001 is fairly unspecific about when updates to a XEP can be published
> (ie, when PRs can be merged). More or less, it says they should be, but from
> Stable onward only with Approving Body permission.
>
> This means that during a Last Call updates can be made, changing the XEP
> while people are reviewing it, which seems potentially awkward to me.
>
> Once a XEP has gone before Council, we have developed a habit of discussing
> PRs before a merge to see if they'll clear Council objections - this
> streamlines the logistics but is clearly not what the process demands.
>
> The timeline for a Proposed XEP currently looks like:
>
> t=0 Last Call Starts
> t=2w Last Call Ends, Advancement vote in Council
>
> I'd be interested in views on whether we should require authors hold updates
> to the XEP during Last Call, which would lead to:
>
> t=0 Last Call Starts
> t=2w Last Call Ends, Update Window
> t=n Update Window Closes, Advancement vote in Council
>
> Opinions welcome from Authors, Council people (past and present), and others
> in the community.
This sounds appealing at first glance - however, I think there’s two types of
changes an Author could be making during the LC window: those addressing LC
feedback and those unrelated to LC feedback. Changes unrelated to LC feedback
might not be optimal (but if they need to be made, making them while the LC
window is open actually makes more sense than holding them and potentially
invalidating LC feedback. Changes to address LC feedback make more sense made
*in* the LC window when people can then comment on whether they address their
issues. So I think this comes down to ‘worthwhile changes might as well be made
ASAP, including in LC, and “bad” changes are best not made during LC (or
ever)”, so it’s not clear to me that the change would actually help. I think
the existing process, whereby Council will reject advancement if LC feedback
hasn’t been addressed, would also apply if the Author is making undesirable
changes during or after LC (or another LC could be issued, or whatever).
> 2) Who are Authors anyway?
>
> Authors have special rights with XEPs, especially Experimental - they can
> more or less change them at whim, and although the intent here is that they
> capture community consensus, there is no oversight. Additionally, there's a
> bit of kudos involved in having one's name at the top of a XEP.
>
> In practice, Council has added (and removed?) Authors, and we added an
> "escape" to XEP-0001 in the form of Document Shepherds.
(I can’t remember Council ever removing an Author, although Authors have
removed themselves. My memory may be imperfect)
> What I'd like to propose here is that XEP-0001 properly captures who Authors
> are (initially, the original Submitters listed on the document, all of whom
> must agree to the IPR policy)
That seems reasonable
> , how new ones are added (by Council approval, in consultation with the
> existing Authors if possible),
I think Authors should be free to add additional authors, as they’ve previously
done.
> and how dormant/inactive Authors are removed (here be tygers; I'd like to
> propose maybe marking them as emeritus or something less latinate).
Although I’m not convinced it’s a good idea, we could move to recording who has
authored each change to a XEP, and instead of having an Authors list being
responsible for the XEP, have a Maintainers list or whatever, and have Council
able to manipulate the Maintainers list, but not the authors list (which is
then simply a factual record).
> I'm not bound to this approach, but I think done correctly, this can obviate
> the need for Document Shepherds entirely, so this might - astonishingly -
> simplify our process.
I’m not sure it simplifies the process significantly, as you still need to have
someone in the Document Shepherd role, as it currently stands, whatever name
one gives it.
Regardless, nothing here is remotely a hill worth dying on, and at least some
sort of codification of what we’re doing (or changing what we’re doing to match
our process) makes sense to me.
/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
