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

> 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 <mailto:florian@rivoal.net>>
> Date: Wednesday, 26 June 2019 at 10:59
> To: "David (Standards) Singer" <singer@apple.com <mailto:singer@apple.com>>, W3C Process Community Group <public-w3process@w3.org <mailto:public-w3process@w3.org>>
> Subject: Re: DRAFT agenda for the regular Process Call Wednesday 12th June 7am PDT
> Resent-From: <public-w3process@w3.org <mailto: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 <mailto: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 <https://www.w3.org/wiki/Repositories#Recommendation>>
>>> and its supporting issue
>>> <https://github.com/w3c/w3process/issues/168 <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 <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/ <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 <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