Re: DRAFT agenda for the regular Process Call Wednesday 12th June 7am PDT

Incidentally, to be more effective, sending proposals at 3 in the morning
(Pacific time) before a 7am call guarantees I won't be able to even glance
at it ahead of time.

On Wed, Jun 26, 2019 at 6:58 AM Florian Rivoal <florian@rivoal.net> wrote:

>
>
> On Jun 26, 2019, at 22:52, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
>
> Thanks for this, there’s one feature of this proposal which I expect to
> cause friction:
>
> This change envisages that registry content is *included* in RECs, and
> enforces that updates to registries are made by updating their containing
> REC. That in turn means that any dated reference to the REC will become
> outdated by a registry change when *no other change has been made*.
>
> I’ve noted previously that this pattern does not fit with common usage of
> registries, where the registry content is *referenced* by the REC, which
> therefore does not need to change at all to accommodate changes in value.
>
> The obvious get-out to address this would be to make a REC that only
> contains a registry, and reference that normatively from another REC.
> Introducing that as a pattern could work;
>
>
> That's the intent: you can either include the registry inline in a larger
> spec that uses it, or making place it in a standalone document.
>
> we should be aware that it imposes a much higher bar for publication of
> registry content than has been set until now, where registries can take the
> form of a WG Note
>
>
> Setting up the registry initially would take some work, but that's would
> be effectively to get the buy-in on the rules of the registry that are
> necessary to guard its stability. Once created, it can be updated by a
> simple invocation of echidna.
>
> Also, technically, Notes are Technical Reports too, and the definition
> proposed allows them to be placed in any Technical report (Not 100% whether
> this is intended by fantasai). However, the rules of the registry could be
> updated with less scrutiny there than in a REC track document, so this may
> not be ideal.
>
>
> a wiki page etc. I would expect some degree of push-back against that
> imposition on that basis.
>
> Kind regards,
>
> Nigel
>
>
> From: Florian Rivoal <florian@rivoal.net>
> Date: Wednesday, 26 June 2019 at 10:59
> To: "David (Standards) Singer" <singer@apple.com>, W3C Process Community
> Group <public-w3process@w3.org>
> Subject: Re: DRAFT agenda for the regular Process Call Wednesday 12th
> June 7am PDT
> Resent-From: <public-w3process@w3.org>
> Resent-Date: Wednesday, 26 June 2019 at 10:59
>
>
>
> On Jun 25, 2019, at 7:29, David Singer <singer@apple.com> wrote:
>
> 2) We need to make progress on Registries. Please review the Wiki text at
> <https://www.w3.org/wiki/Repositories#Recommendation>
> and its supporting issue
> <https://github.com/w3c/w3process/issues/168>
>
> I would like consensus to take this
>   a) into Process-text drafting
>
>
> Based on this (as well as the similar
> https://www.w3.org/wiki/Maintainable_Standards#Registries), Elika and I
> (mostly Elika) have drafted possible Process-text to implement registries,
> using today's process as the starting point.
>
> The changes largely fall into two categories:
> * Defining what a registry, and a change to a registry, are. This is
> agnostic to the existing REC Track vs evergreen vs any other track we may
> eventually design.
> * minimal tweaks to the REC track to allow for registry updates without
> triggering transition calls or other overhead-heavy process
>
> You can preview the document with the changes incorporated here:
> https://w3c.github.io/w3process/registries/
>
> Or in diff form here:
>
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Fregistries
>
> The changes are in:
> * 6.2.5 on classes of changes
> * 6.3 which defines registries
> * 6.5.1 for no-overhead revisions to a CR for registry updates
> * 6.6 for allowing PR without implementation of all entries in a registry
> * 6.8.2.3 for allowing  no-overhead revisions to a REC for registry updates
>
> We hope that concrete text will make discussion during the call easier.
>
> —Florian
>
>
>