W3C

– DRAFT –
Revising W3C Process Community Group

10 March 2021

Attendees

Present
cwilso, dsinger, fantasai, florian, plh, wseltzer
Regrets
-
Chair
-
Scribe
fantasai, jeff, plh

Meeting minutes

4 items for 2021 Process

Tooling Policy

david: [talks about the AB CfC]
… should/must for retention records

jeff: which CfC was that?

Jeff: the AB CfC did not get the 8 supporters and got a -1 from me
… regarding getting should/must
… so we didn't get AB consensus on this one

David: so we got a lot of people missing

florian: I don't think we're done going through the conclusions from the AB but no one changed their support
… there will be request for changes to the wording in any case

jeff: agreed, I think we can make some progress on this

jeff: agreed that it has to be a must ultimately

fantasai: for the implementation of must for minutes/decision, we're not far away
… we're not deploying the process immediately. don't think we'll have troubles to bring everyone in line

david: ok, should try to revise the wording and wait for plh to give the results of his survey

jeff: one Group was sloppy in the past

jeff: it's easy if the group wants to do it but if the group does not want, we'll need to discuss with them

<jeff> PLH: I don't imagine a group refusing

<jeff> ... could be a technical problem

... may want a system to drop GoogleDocs into an email/gh
… don't have tools today

Florian: Tool is trivial: export to PDF, send an email, done

PLH: If you do it manually

recording meetings

david: should we defer and take it offline?

florian: agreed

<jeff> s/differ/defer/

florian: for routine meetings, we shouldn't have recordings but there might be exceptions for some meetings

david: I don't have strong feelings. let's the discussion going on github

Chris: we have an internal discussion on this as well and no conclusion yet

David: same for us

fantasai: we could put the part about not doing it unless there is consent

<cwilso> +1

fantasai: we can adopt what david has and further refine

https://github.com/w3c/w3process/issues/334#issuecomment-793173149

chris: current is more that just consent

florian: we can adopt unless it's too strong

chris: yes, this is fine

<cwilso> +!

<cwilso> er, +1

Proposed: Adopt David's proposed text and continue the discussion for further tweaking

<Zakim> jeff, you wanted to make a small point about recording of meetings

Jeff: I noticed a pushback from Dom.

Florian: it's against my further restriction, not against David's text

Jeff: also there is text that I'd like to see in the Process and not the Guide
… the current proposed text doesn't balance things well

fantasai: you're asking on the informative, not the normative part?

Jeff: correct

<wseltzer> +1 to deleting the Note

David: we could delete the Note and we could push all of the guidances to /Guide

wseltzer: the single normative paragraph should go in the Process, and the rest should go into the Guide

fantasai: would suggest to delete the first sentence of the note and keep the second, which is an example showing why the retention policy matters. But I'm ok with not having the note

florian: let's not have the Note for now

fantasai: fine

david: fine by me

Resolution: Adopt David's single paragraph policy and continue the discussion for further tweaking

<wseltzer> The text: [[No-one may record a meeting, or retain an automated transcript, unless the intent is announced at the start of the meeting, and no-one withholds consent. If consent is withheld by anyone, recording/retention must not occur. The announcement must cover: (a) who will have access to the recording or transcript and (b) the purpose/use of it and (c) how it will be retained (e.g. privately, in a

<wseltzer> cloud service) and for how long.]]

Registries

<dsinger> Registries: see also <https://lists.w3.org/Archives/Public/public-w3process/2021Mar/0001.html>

fantasai: let's tackle the question about accepting the process overall and then there is a further refinement to consider

florian: the base branch is an evolution: separate track, no CR phase.
… shouldn't be controversial
… for the additional part, it's about publishing the registry tables in a separate technical report
… if we agree, there will be some details to work out

<dsinger> https://www.w3.org/Consortium/Process/Drafts/registries/

david: are we ready to adopt https://www.w3.org/Consortium/Process/Drafts/registries/ ?

<dsinger> https://www.w3.org/Consortium/Process/Drafts/registries/#registries

<Zakim> jeff, you wanted to go back to recording of meetings when we are done with registries

Proposed: adopt https://www.w3.org/Consortium/Process/Drafts/registries/#registries

<Zakim> wseltzer, you wanted to discuss Registry Reports and Patent Policy

wseltzer: just noticed the exclusion from the patent policy
… not sure there is complete agreement

david: registry is purely informative
… implementation requirements are to go in Rec-track

wseltzer: better way to express that then

https://www.w3.org/Consortium/Process/Drafts/registries/#rec-advance

Working Groups can also publish registries in order to document collections of values or other data that have no normative implementation requirements. Registries are generally companion to Recommendation Track documents which contain the related normative requirements, and are typically published in a separate registry report, although they can also be directly embedded in Recommendation Track

documents. The registry track requires wide review and consensus on what the registry will contain and how it will be managed. Once set up, changes to registry entries are lightweight and can even be done without a Working Group. See § 6.4 The Registry Track for details.

florian: since the reigstry track is not the rec-track, it's excluded from the patent policy construction
… we could tweak this sentence, but things that can be subject to the patent policy don't belong in the registry track

wseltzer: makes sense
… but let's avoid contention, so better phrasing would be good

fantasai: we could move text around after the merge

wseltzer: or eliminate the first clause, or better, the entire bullet point?

david: I can live with that

fantasai: it's good to remind folks about what's happening
… we don't talk about the patent policy otherwise in that section which is why it's confusing. The intro section should talk about it.

florian: preference for merging as-is and tweaking later

wseltzer: I'm ok with merge+tweak if we do the tweaks quickly
… we'll need a draft to PSIG soon

florian: ok to do the tweaks quicky

Resolution: adopt https://www.w3.org/Consortium/Process/Drafts/registries/#registries

https://github.com/w3c/w3process/commit/671735ae81050ab52a9f00921c4c81bd12e4dc54

https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fregistries%2F&doc2=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fregistries-separable%2F

https://www.w3.org/Consortium/Process/Drafts/registries-separable/#reg-pub

new section defining registry data reports https://www.w3.org/Consortium/Process/Drafts/registries-separable/#registry-data-report

<wseltzer> +1 to "tweaked version"

Florian: you can link to a separate document for the tables

https://github.com/w3c/w3process/issues/503

<dsinger> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fregistries%2F&doc2=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fregistries-separable%2F#reg-pub

<dsinger> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fregistries%2F&doc2=https%3A%2F%2Fwww.w3.org%2FConsortium%2FProcess%2FDrafts%2Fregistries-separable%2F#reg-data-reports

david: it seems simple enough

florian: you can always publish a /TR document in multiple files

fantasai: This is just about whether you can publish the tables under a different shortname from the registry definition

david: so if I want the registry definition and the table , can I do that under the same /TR?

plh: Trying to understand. have a document called a registry, publish on registry track

plh: Now you're proposing in order to publish separately the tables, need to add a new type of technical report called a "registry data report"

dsinger: So that you can back it by a different automated system

dsinger: registry data reports exist in this boundary state, they're not controlled by the Process

dsinger: are they technical report or not? Kindo fon the boundary

<Zakim> cwilso, you wanted to suggest, BTW, that PSIG should be informed of registry plans to make sure they don't have advice.

cwilso: We should know PSIG about registries, btw

florian: soon, but not just yet, we have some sentence to tweak as wseltzer requested :)

florian: The registry report, when it contains everything, contains two pieces. one is the rules and the other is the table.s

florian: If you want you can have all of that in a REC

florian: You can also have it as a separate document on the Registry Track

florian: When you have both the rules and the tables, that's a Registry Report

florian: The question is, can you have the tables separate from the rules.

florian: I believe this is mostly not useful.

florian: Given we can have multiple files in a publication

florian: like CSS2.1 is multiple chapters

florian: ...

florian: The change we're discussing right now is whether we should allow the tables in a separate *technical report*

florian: If we don't adopt the change, you can put everything in a REC, or everything in a Registry Report.

florian: If we adopt the change, then can split the Registry into two reports, one for the rules and one for the tables

dsinger: Florian and I disagree on whether this is necessary

florian: I dislike it, I think it's unnecessary, but I can live with the way it's drafted rightnow

+1 to florian from fantasai

wseltzer: I support this change

wseltzer: I think it helps people who are familiar with IANA process

dsinger: I think we avoid the mistakes of ISO/IANA of hosting the registries in different organizations

dsinger: couldn't find tables for XXX for example, which is appalling

dsinger: I like what we have here

dsinger: My take is, given the inconclusiveness of the survey, send it out for review with

florian: My alternative proposal is leave it out for the year, if it's actually needed and requested, we can add it next year

florian: Wrt the survey, was "2 considered it harmful" and "2 thought it necessary". We followed up, one of the "harmful" ppl was just confused, and one of the "necessary" people concluded it's not actually necessary

plh: I like the flexibility of the proposed addition

plh: Makes things slightly more complex

plh: but gives a bit more flexibility also

dsinger: OK, let's merge with this. Fix it up so we can send to PSIG

dsinger: No decision is final, still have to get through AB and informal AC reveiw, and formal AC review

Action: wseltzer to do a patent-policy focused review of registries

florian: Don't like it, not objecting.

Resolution: Merge separate registry tables reports change.

fantasai: Do we want to highlight the change with <INS> or just leave it and let people notice or not?

dsinger: Let's not highlight the issue.

recording of meetings

<Zakim> jeff, you wanted to go back to recording of meetings when we are done with registries

jeff: I reread Dom's posting, and not convinced dsinger's text is consistent with it

jeff: Gives example of workshop and recording presentations without everyone's consent

wseltzer: Even for presentations, consent is required. Might be easier to get consent, but still require it

note-track

florian: Didn't do my homework on opening new issues, one on bikeshedding TAG documents, and the other on the switching-tracks question. I'll do that soon.

[discussion of meeting and review scheduling]

Meeting adjourned.

Summary of action items

  1. wseltzer to do a patent-policy focused review of registries

Summary of resolutions

  1. Adopt David's single paragraph policy and continue the discussion for further tweaking
  2. adopt https://www.w3.org/Consortium/Process/Drafts/registries/#registries
  3. Merge separate registry tables reports change.
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

Diagnostics

Succeeded: s/trivial/trivial: export to PDF, send an email, done/

Succeeded: s/differ/defer/

Failed: s/differ/defer/

Succeeded: s/david/florian/

Succeeded: s/is/us/

Succeeded: s/we could keep some of the sentences from the Note/would suggest to delete the first sentence of the note and keep the second, which is an example showing why the retention policy matters. But I'm ok with not having the note/

Succeeded: s/first clause on that sentence/first clause, or better, the entire bullet point

Succeeded: s/section/section which is why it's confusing. The intro section should talk about it./

Maybe present: Chris, david, jeff