[Standards] Process Wonkery

Kevin Smith kevin.smith at isode.com
Mon Oct 4 14:37:50 UTC 2021

On 30 Sep 2021, at 09:56, Dave Cridland <dave at cridland.net> 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).


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


More information about the Standards mailing list