[Standards] A Meta-Discussion about the Standards Process

Dave Cridland dave at cridland.net
Thu Jan 16 22:59:09 UTC 2020


On Thu, 16 Jan 2020 at 22:15, Peter Saint-Andre <stpeter at mozilla.com> wrote:

> On 1/16/20 2:49 PM, Dave Cridland wrote:
>
> [ historical inaccuracies elided :P ]
>
>
Fake news, doubtless.


> >     > Peter Saint-Andre (I think) designed our standards process to
> >     avoid the
> >     > Internet Draft stage and go straight to the wild-west of
> Experimental,
> >     > but it's otherwise the same as the original IETF design.
> >
> >     Originally, the Editor (me) accepted anything for publication as a
> JEP,
> >     after minimal coherence / formatting checks and IPR assignment. Then
> the
> >     Council decided it wanted to act as a gate to publication, which is
> how
> >     got here. Instead of adding more epicycles, I propose that we remove
> the
> >     one we added. Consider me in favor of the "Daniel Plan".
> >
> > I can easily be persuaded to go for the Florian Plan (or indeed the
> > closely-related Kev Plan), but I rather lean toward the Daniel Plan - as
> > you note, it fits the history of the XSF much better. I would be
> > fascinated to hear the original reasoning for the Council wanting the
> > veto in the first place, and I doubt it has much to do with how it's
> > used now.
>
> Control. Power. The usual suspects. ;-)
>
>
Oh, so my doubts were misplaced? ;-)


> I don't exactly recall - we'd need to look at the list archives. But I'd
> say this happened in 2004 or 2005 because, for instance, XEP-0143 went
> directly to version 0.1 on 2004-09-15 whereas subsequent specs underwent
> several and sometimes multiple revisions based on Council feedback
> before being published as XEPs.
>
>
Interesting; I didn't realise it was that late.


> > My concern is that on several occasions the Council has been the only
> > thing preventing encumbered specifications from entering the Standards
> > Track, so I think this use of the veto is risky to lose entirely.
>
> Did we receive any encumbered specifications before ~2004-2005?
>
>
Probably not; but I wouldn't know, I'm a latecomer from 2006/7. I don't
remember any mention of any.


> Did this issue even arise back then, and if not does it make sense to
> attribute this magical power of saving us from encumbered specifications
> to the Council?
>

It has arisen since, and Council seem to have spotted each case and stopped
it entering the Standards Track.


> How do we determine that specifications are encumbered and do we
> actually need the Council for that?


Well, we need someone to make the decision and take the blame. Some
decisions are easier to make with a voting committee than trying to read
consensus (and who would do that consensus call, anyway?).

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200116/0fcf95b9/attachment.html>


More information about the Standards mailing list