W3Process CG -- 26 Jun 2019

<scribe> scribenick: wseltzer

<scribe> Agenda:

<dsinger> https://www.w3.org/wiki/Registries#Recommendation

dsinger: I've linked a wiki
... on which we've been working for several months

https://www.w3.org/wiki/Registries#Recommendation

dsinger: questions?

jeff: [garbled]
... We'd included some Evergreen process discussion of registries
... Should we now remove that special case from Evergreen?

dsinger: this was written with same continous review process as for Evergreen

<plh_> https://www.w3.org/2019/03/Evergreen.html#Registry

dsinger: is the green text the only ref to registries in Evergreen?

plh_: also 6.11 has mention of "except for registries"

dsinger: we'd do a meld of the two

<plh_> https://www.w3.org/2019/03/Evergreen.html#evergreen-rec

<Zakim> nigel, you wanted to mention I did read it and replied but not on the GitHub issue - comms around this are parallelising

nigel: I responded to email, then there's a github issue
... where are we talking?

florian: I apologize for posting duplicate text
... proposed Process text with Elika
... to make registries not depend on evergreen
... it defines a registry, and makes minor changes to the rec track
... definition is insipred by dsinger's wiki
... adds a 5th class of changes to those defined in Process today (editorial and substantive)
... three changes to the rec track
... CR, updating rec,

<florian> https://w3c.github.io/w3process/registries/

<Ralph> diff of proposed changes

<florian> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Fregistries

<florian> * 6.2.5 on classes of changes

<florian> * 6.3 which defines registries

<florian> * 6.5.1 for no-overhead revisions to a CR for registry updates

florian: I'll point to changes

<florian> * 6.6 for allowing PR without implementation of all entries in a registry

<florian> * 6.8.2.3 for allowing no-overhead revisions to a REC for registry updates

<Ralph> [typo in "6.8.2.3. Revising a Recommendation: Regsitry Changes"]

<Zakim> wseltzer, you wanted to say this interleaving is confusing

wseltzer: I'd prefer to do the work of Registries in Evergreen
... and I find the interleaving of Registries into existing Rec track confusing

Ralph: I disagree
... while I'd like to see Ever* proceed
... I think this is a useful step to include registries in existing rec-track process
... it's ok that this doesn't address all parts of the wiki

dsinger: 6.3 is missing the requirement that all normative reqs of registry and definition of essential must be in containing doc, not registry
... to detach from PP
... you can also have a section in a normative doc that "this section is a registry" and not intended to be normative
... also, I want us to have registries available to more than just Recs

<fantasai> dsinger, if a CG wants to publish a registry it can do so alrady

dsinger: all the rules in the embedding doc, which could be CG Report

<fantasai> dsinger, we don't need to provide a facility in the Process because CGs are not governed by the Process

Florian: this wasn't meant to be an alternative, just removing dependency
... since the way we publish today is through Rec track
... updated that
... Note @@
... the comments dsinger made are friendly amendment
... there's a statement someone re IPR commitmebt
... untangling with Evergreen track and entangling with Rec publication

fantasai: a Rec can be only "this is the rules for a registyr, and here's the registry"
... though can also be embedded

<Zakim> nigel, you wanted to ask what we do about existing non-Rec registries if we take this proposal forward

nigel: is this saying all registries have to be in Recs?
... but there are already a whole bunch of other documents claiming to be registries
... notes, cg reports, wikis
... if we adppt this, what happens to those?

fantasai: we're not changing those other things

nigel: I know at least one W3C Note that claims to be a registry

fantasai: this is a particular type of registry as a TR

<dsinger> “This is a W3C Registry for YYY as defined in XXXX” is a different statement from “this is the YYY registry”

fantasai: it stays subject to its own rules

dsinger: registries under new rules would say "this is a W3C registry [link]"

<Zakim> florian, you wanted to respond to wendy's "untangling with Evergreen track and entangling with Rec publication"

florian: I don't agree with wendy's characterization
... the only way we publish today is rec track
... so we use that now

jeff: [garbled, still]

<plh_> Jeff: so, should we delete registries from the evergreen proposal?

[squawk]

jeff: if we think intro of registries to rec track is sufficiently agile that you'd never want evergreen
... then there's no need to define it in evergreen
... if that's where we want to go, drop from evergreen
... but if you could imagine wanting both, leave it in
... where does this esteemed group want to go?

fantasai: we make it so easy there's no reason to go to evergreen

<nigel> +1

fantasai: if you want to embed a registry in a TR
... e.g. a mapping table
... could make it easier to update
... if the doc moved to evergreen, registry could too

<Zakim> florian, you wanted to speak after jeff

florian: agree Elika
... propose to delete registries from EG, rebase on top

[wseltzer: -1]

scribe: and tweak

dsinger: you also miss the requirements of registry hosting, e.g. hosted so they preserve history

florian: those are built into existing "publishing"

dsinger: only in fthe registry is embedded in doc

florian: In my proposal, a document is the registry

dsinger: the *rules* must be on the rec track, the content need not be

florian: in my proposal, the content is on the rec track in a special mode

dsinger: don't think the lawyers will be happy disentangling

<dsinger> https://www.w3.org/wiki/Registries#Recommendation

<Ralph> [some registries are Recommendations, some registries are parts of Recommendations, some registries are maintained outside of Recommendations. The Florian/Elika proposal clarifies how registries that are inside Recommendations may be maintained]

fantasai: content of the registries intended to be in the document
... document can be a table
... it's a bunch of structured entries embedded in rec track doc TR
... not externally

<dsinger> I would encourage you to look at complex large registries such as http://mp4ra.org/#/

fantasai: makes it easy to see all entries in the report
... archives, URL for latest version
... you don't have to use particularformat, but have to put it in the document
... gets us archiving, accessibility, stability
... we don't get those guarantees elsewhere
... you can't publish on site W3C doesn't control

dsinger: look at complex registries, IANA, mp4ra, not manageable as a document
... there are many registries much larger and more complex

florian: do we need to support registries that are SQL-based

<jeff> David: possibly

<fantasai> I'm not seeing anything in MP4RA that isn't reasonable to represent in this way

florian: if we allow anything, hard to make rules

<Zakim> wseltzer, you wanted to say that's more confusing

<fantasai> wseltzer: I like the idea of speaking to someone who needs a registry

<fantasai> wseltzer: maybe it's possible to infer from REC track, but would prefer a separate "here's how you do a registry"

<Zakim> nigel, you wanted to agree that Recs that are only Registries is overloading Rec

<fantasai> wseltzer: I would prefer an laternative to "registry looks like a technical report"

nigel: if you're going to have 2 classes of Recs iwth different update requirements
... a Rec that's only a registry has great difference from Rec that's a spec
... overloading "Rec" too much
... a different class of doc is needed

<dsinger> akc flo

florian: double intent
... we don't have to describe 2 kinds of Rec or ways of updating them
... we already describe kinds of updates
... we're describing an extra category of changes that can be updated
... This allow both stand-alone and in-line registries
... and re-uses tooling

<dsinger> https://www.w3.org/wiki/Registries#Recommendation

dsinger: I had hoped to start from wiki, ask people if they see anything problematic
... and yet got what looks like an alternative

florian: what you wrote on wiki doesn't feel like a process
... it needs process rules, and we proposed process rules
... I thought we were instantiating what you wrote
... if not, you might need to write more detail
... it wasn't meant to be an alternative

<dsinger> (note that the #Recommendation section is not entangled with evere-whatever)

<fantasai> (yes, but it's not a Process, it's a requirements doc)

Ralph: I read it as florian describes, but concern is that it isn't complete instantiation
... to dsinger's question, how do we proceed?

dsinger: sounds as though no one has problems with what's on the wiki
... but we need to revise text
... shall I contact those who commented on the issue?

florian: suggest we first work to figure out why you think our text is not a a concrete instantiation of your requirements document

dsinger: I think it's urgent to get feedback from people who want registries

florian: how does it help us to review wiki?

dsinger: learn whether there are blockers, missing elements

<Ralph> [a full implementation of what's in https://www.w3.org/wiki/Registries#Recommendation is IMHO likely to be more complex and may well be better done in the context of Ever*]

dsinger: the process text needs at least IPR rules

fantasai: I want dsinger to explain what aspects of the wiki aren't covered in draft text

<dsinger> https://www.w3.org/wiki/Registries#Recommendation

dsinger: I want to find out whether we're addressing the issues of people who want registries

jeff: good idea to talk with them about what they want
... and to work with florian and fantasai on draft process text
... but that's not complete
... as we've also heard concerns about complexity from wendy and ralph

<Ralph> [I would propose that a useful question is 'Is the Florian/Elika proposal a useful interim step to something more complete?']

florian: I reserve the right to find comments unhelpful if they're on wiki rather than text

<Zakim> nigel, you wanted to ask if folk are welcome to update the Registries wiki if they see things that need to be addressed?

nigel: How should we review the wiki?

dsinger: minor edits do in-place
... larger issues, raise on list

nigel: issue of format. I know of some registries that are XML

dsinger: fine to clarify that we're agnostic

florian: if you need to be able to handle registries that can't be handled as text, say so

dsinger: mp4ra is dynamically generated from csv
... see ^

<dsinger> see MP4RA at https://github.com/mp4ra/mp4ra.github.io

florian: you need to characterized the complexity

dsinger: does anyone have problems with editorial improvements?

<Zakim> jeff, you wanted to ask if the chair plans to respond to my last comment

jeff: are you also addressing Wendy's and Ralph's objections?

florian: I'd address complexity in /Guide rather than Process

<Ralph> [my comment was not intended to be interpreted as an objection to Florian/Elika's text]

[I will prpose an alternative way to proceed]

dsinger: Ralph and Wendy and I can work through concerns

Calendar

dsinger: I can do July 24, but can't be available on the 10th
... it's an MPEG meeting

jeff: propose we work together more offline

dsinger: cancelling July 10, will make async CfC on other issues
... next call 24 July.

<Zakim> wseltzer, you wanted to chair on the 10th

[adjourned]

- DRAFT -

W3Process CG

26 Jun 2019

Attendees

Contents

Calendar

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output