W3C

– DRAFT –
Revising W3C Process Community Group

16 September 2020

Attendees

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

Meeting minutes

Agenda corrections

David: Any corrections?
… none

P2020

David: It is published and linked
… Congratulations

All: [clapping]

Consensus on issues

#428

David: PLH seems to want to leave it open
… don't know why

Florian: PLH pointed out that we may want to use it in the future
… but he has now marked it as approved

David: Objections?

[None]

<dsinger_> #428 approved to pull

David: PR #428 is approved

#262

David: Proposal to add a single sentence
… but Nigel's comment

Florian: Nigel's comment is an orthogonal issue
… problem in existing text

David: We should file an additional issue

Florian: I think so
… his problem with context above

David: Comments?

[None]

<dsinger_> #262 approved. new issue needed for the new question

David: Pull request #262 is approved.

Fantasai: Are we dfn'ing it?

David: No

#438

David: Some dissent about how much of a note we need

Florian: Dissent seems to be within the team
… Ralph v Wendy

David: Wendy supported by me and Chaals
… Jeff can you resolve within the team

Jeff: Not really

Florian: I'll take it.
… Can we take a tentative resolution that on point (c) we delegate to Wendy and Ralph and accept everthing else
… ?

David: You could do the base effort and keep the issue open about the note.

Fantasai: You can include the note with the prefix "Issue"

David: Let's do that

<dsinger_> #438, not agreed, we have continuing dissent over the note; we will pull with the Note as an issue, to enable progress

Florian: Prevents branches on top of branches

#449

David: Process has been published without the change
… should we do for next year

Florian: Drop Amended REC so there is no conflict

Fantasai: Should be OK
… new items are Proposed Corrections/Additions
… outside of Process Doc noone sees the term Proposed Change

PLH: Part of this is to help people understand
… discussed recently with Fantasai
… let's first get rid of Amended REC
… shouldn't hurry
… let's revisit in 3 months

David: Rename for this process since it is a better name
… sounds like agreement to incorporate #449.

Fantasai: I like calling Amended REC - "Team Amended REC"

<dsinger_> agree to incorporate #449 and gain experience. (a revisit will need a new issue)

Fantasai: even without a conflict

Registries

David: Got logjammed last year
… then we finished Ever*
… I relooked
… it is long
… tried to simplify
… took a fork
… can define state of registry by looking at state of its recommendation
… when reach REC, registry become formal
… Then, do you need a CR?
… There are no implementations
… why have a CR phase
… but it is a signal to a WG
… still need signal
… ask for experimental registrations
… consider whether they would work
… well defined?
… are the fields all there?
… so let's say that a registry definition is part of a ReC
… that's what I built
… some names unclear (e.g. Registry report)
… apologize for failure to bikeshed

<dsinger_> my draft at <https://‌github.com/‌dwsinger/‌w3process/‌blob/‌registries/‌index.bs>

David: could we pursue this direction
… clearly need work

PLH: 2 things
… 1. Ralph would like to help with this.

<plh> https://‌www.iana.org/‌assignments/‌provisional-standard-media-types/‌provisional-standard-media-types.xhtml

PLH: 2. How is CR phase different from provisional list of IANA
… I saw James' email
… renaming incubation to experimental
… match IETF
… same for registry?

David: Yes, during CR, registry is provisional

PLH: You should consider it

David: They have provisional registration. This is a provisional registry.

Fantasai: Exactly. That is provisional entries; not a provisional registry
… all the values are in the registry unprovisionally

David: Not quite the same
… thanks for Ralph's help

<Zakim> fantasai, you wanted to reply about provisional

Florian: Interesting step forward
… will crack it from here
… I'll rebase to latest version
… will update pre-existing version
… prevent accidental differences
… two differences
… 1. that you talked about
… we already have recognized "no implementation to work for"
… 2. If in a standalone doc with no implementable requirement
… then also nothing for PP to cover
… why involve lawyers?
… so we have similar to REC track; removing irrelevant bits
… I will try a rewrite
… need to think about residual value of CR phase
… if not we can simplify further
… or a longer process that is easier to run through
… sync editorially will help that
… 2. Previous version allows registration and definitions in REC or standalone doc

<fantasai> dsinger, you can't skip exclusion. The Patent Policy defines itself to apply to the Recommendation Track.

Florian: but not split between the two
… not quite objecting strongly
… but I see tension

<fantasai> dsinger, so as long as you're putting a document on the Recommendation Track, the Patent Policy will apply to it

Florian: strong coupling
… can't read a table without knowing the purpose of columns
… so duplication if not in same doc
… could be annoying
… also not clear what to link to - single concept in 2 docs
… revisions are easy
… a conforming historical version of 2 docs is annoying (though possible)
… without value to separate, why tolerate these annoyances?

James: I bring ignorance of existing process
… how is this seen outside the org
… other factors to consider
… how is it communicated?
… how would outsiders understand it; and the importance?
… simplification is good
… aligning with external processes are helpful
… use terms that align with what people are familiar with
… e.g. ITIL (IT information Library)
… basis for many dev op processes
… has a familiar lexicon

David: Please send to process ml

David: We have no process for registration
… we have some in tables in a REC
… separate REC
… wiki, gh repo
… all over because we lack a preferred way to do it
… unclear who has authority to update
… are they keeping history
… need to clean up

<Zakim> dsinger_, you wanted to suggest the possibility of implementation-free Recs and skipping exclusion

David: For exclusion opportunities
… we have other RECs with no implementation phase
… focus on terminology
… could simplify lawyer's life by saying not implementable
… would require PP change
… might not be worth it

Fantasai: Definitely not

<Zakim> florian, you wanted to respond to james

David: May be easier to leave it in

Florian: Ease of understanding by external people is part of why we have a separate track
… for internal people - easy to understand as a REC
… for external people - much easier as a standalone
… avoid amendment process, etc.
… not needed for registry
… who do we optimize for?

David: On the split question
… I operate MP4 RA
… 99% readers look at RA to understand meaning of 4 character codes
… true for IANA as well
… hierarchy of constituents
… most common usage is lookup
… very few read the definitions
… only to register a new value
… fine to publish together
… but shouldn't require it
… realize it is a ditch.

<Zakim> dsinger_, you wanted to comment on the split

Jeff: Can you have 2 copies of the value table (one non-normative) to simplify the lookup

David: Rather not

PLH: We can do tooling on top to provide the same information in a different way

David: I would like that to be the small amount that defines the table.

<Zakim> florian, you wanted to propose how to move forward

Florian: I will update your thing to the latest version
… tweak my part
… focus on the differences for the AC presentation
… get the AC input
… I would like to hear from a broader audience

<fantasai> +1 to hearing from a broader audience

David: I agree with what you say

<fantasai> specifically on these two questions

Jeff: Deadline on Monday for AC presentations

David: Yes

David: You should not have conformance depend on definitions in the registry
… registry is mutable
… this is not exclusive to registries
… I included a note in my write-up
… so this observation is a more general observation
… but an easy mistake to make
… do we need this warning in registries

Jeff: If we know we need it here, let's put it here
… worry about the rest later

Fantasai: I agree

Florian: Seems reasonable for now

James: Much implementation happens before CR
… important dependencies happen before REC phase
… mapping dependencies are quite difficult
… may depend on IETF experiment; on a doc in incubation phase
… hard to understand current state
… may be fixing the problem after the horse has bolted
… work is overly finalized before REC phase
… a reality that we face

Fantasai: That is a separate topic
… Can't control implementations
… or the timing where proposals come up
… some times need to push forward to align
… can we have some conclusions
… sync the two options
… create an AC presentation to collect more feedback

David: I use the word "referencing REC" for something that uses registry
… "registry definition" for the definition
… "registry report" for instantiation
… we should simplify the terminology
… call the tables "W3C registry"
… opinions?

Florian: Agree it is awkward
… many animals to name
… it is hard
… they are bad
… but may end up with fewer things once we are done

<Zakim> dsinger_, you wanted to ask about names

David: We should revisit at end
… anyone object to calling it W3C registry for now?

Tantek: Look at what names people are using
… accept as much as possible

David: Let's simplify along those lines

Florian: Bikeshedding is hard
… we don't have a lot of time before the AC call
… issues with W3C Registry
… maybe we will drop it; for now the word is used already
… let's not have the same word mean different things in two branches

David: We'll put it on people's radar.

James: On naming, can delegate to a subset
… 50% of time (for recent charter) related to choosing names

<Zakim> fantasai, you wanted to get a resolution so we can move forward

Fantasai: We should have a resolution

Proposed resolution: Two branches for 2 proposals. Florian to remove gratuitous differences. Request AC feedback.

David: Objections

Resolution: Two branches for 2 proposals. Florian to remove gratuitous differences. Request AC feedback.

<tantek> just a suggestion, we may wish to keep iterating before going to AC

<dsinger_> https://‌github.com/‌w3c/‌w3process/‌milestone/‌6

Milestones

<tantek> assuming we are making progress converging

David: Milestone list is too long
… need to slim down.
… please do that in your spare time

James: What is the deadline

David: No formal deadline.
… this is an attempt to focus our work
… we usually have a draft for the fall
… looking for something in the spring meeting
… followed by formal approval

James: After this group has settled on their proposal?

David: Yes.
… we then get AC review; discussion; ballot
… at that stage we hope ballot does not raise anything new

<tantek> who is minuting?

<tantek> jeff: concerned about the council and voting

Jeff: Can we look at #60
… concerned that STV could be a blocker for the W3C Council

<tantek> I think STV has been problematic yes, both for AB in particular, somewhat for TAG, and would be horrible for the council

Jeff: so I worry we cannot delay it any further

David: That is a different issue from making the text consistent - which is #60

<tantek> so yes, STV is IMO a blocker for the Council

<tantek> October 7?

David: Can we move October 14th to October 7th

<dsinger_> any objections to Oct 7th?

<tantek> wfm

wfm

David: Thanks all
… productive meeting
… accept PRs
… way ahead on registries
… thanks

rragent, make minutes

Summary of resolutions

  1. Two branches for 2 proposals. Florian to remove gratuitous differences. Request AC feedback.
Minutes manually created (not a transcript), formatted by scribe.perl version 123 (Tue Sep 1 21:19:13 2020 UTC).

Diagnostics

Succeeded: s/The/Then/

No scribenick or scribe found. Guessed: jeff

Maybe present: All, David, James