<cwilso> present_

<jeff> scribenick: jeff

David: Do we want to discuss #402?
... previously we decided not
... there is also no proposal

<tantek> Long term I want us to drop our stage names and switch to numbers like TC39

Tantek: As the new person, I agree to defer

David: Let's defer

#403

Wendy: I invited PSIG to give comments
... they are aware where to file commments if they have any

<inserted> General agreement that it's out of scope for 2020

David: Other comments about #403?
... so we can finish by the 24th
... we should inform PSIG of the timeline

Florian: Our text is fine.
... I can take an action to tell them that we have folded it in.
... they can write if they disagree.

<tantek> +1 to Florian's proposal

Jeff: Suggest telling PSIG in their next meeting

#405

Florian: Work should be done offline

PLH: +1

David: We should look at boilerplates in general

PLH: I can set up a wiki page

Florian: +1

PLH: I'll put it in GH and point it in this issue.

Jeff: Let's provide notation in #405 that it does not actually block the process

PLH: Yes, this is implementation

Tantek: +1

<tantek> I agree 405 is adjacent to process

David: Maybe spin it off elsewhere

#406

David: 6.2 does not ack Perpetual CRs
... God, help!

Florian: I would like to push back that we have introduced Perpetual CRs
... takes group consensus to move

s/...God, help!//

scribe: but we didn't actually create a perpetual CR
... we just recognized that sometimes things stay in CR for a long time
... not a new thing, just making CR better while spec is there

David: <pause>

+1 to Florian

<tantek> I'm not optimisitic about issues with discussions this long

<fantasai> scribeNick: fantasai

dsinger_: Do want to disentangle questions of whether labels are appropriate from whether we have a procedural problem

chaals: Agree with Florian, haven't introduced idea of sitting in CR forever
... On the other hand, knowing this is a thing that happens, we have facilitated that
... Nigel and I are amongst those that thing this is not a good thing
... Not sure group will agree to address that issue, but I think we should

dsinger_: Do you have any idea how?

chaals: Rough suggestion I outlined was to put a timer on how long you stay in CR

florian: What happens if you miss?

chaals: You either go to WD or publish a Note
... can take a document from CR to REC and start a new version

florian: If there's not enough implementation success you can't

chaals: You go back to WD

florian: which achieves what?

dsinger_: I don't think we're going to make this change in 2020, much too drastic a change

plh: How are we going to manage WebRTC
... could take even longer
... Don't see what kind of timer we could put

<Zakim> tantek, you wanted to ask to consider guidance rather than force

tantek: I feel sympathetic to aspect of chaals's proposal, also sympathetic that this is not essential fro 2020
... Is there some kind of compromise language that provides guidance?
... rather than something consequential?
... and keep issue open for more precise solution for 2021

florian: I don't have an issue discussing in 2021
... in terms of language to alleviate until then, depends what the language is

dsinger_: I don't think failure to address means we close the issue

tantek: But there are people who want something addressed in 2020
... Acknowledge the discomfort with the state

<Zakim> dsinger_, you wanted to talk about CR quality and Rec quality

dsinger_: would be fine with something along those lines
... I do want to come back to the proposed text

<tantek> URL to proposed text?

dsinger_: We have quality requirements for CR, has to be written to level of quality required of REC: is complete, is consistent, addresses comments, etc.
... These are different from REC which include all those reqs PLUS interoperability of implementation
... There's continued confusion
... To enter CR, whether intending to revise or not, needs to meet a certain quality bar
... AC doesn't check this, but Team does
... If this isn't clear in the Process, could make that clearer

<Zakim> wseltzer, you wanted to suggest drop it

fantasai: These issues were filed by pal with specific concerns, should focus on trying to make the clarifications he's asking for, not open a discussion on how to push groups from CR to REC

wseltzer: I don't think we should try to address for P2020

jeff: Heard ideas around timers for CR, can explore for 2021, but don't think we can address for P2020 right now
... Have been discussing with standards process with Membership
... Membership has been comfortable with perpetual revision. Has not heard of anything like a timer.
... If we add one now, we have to rewind back P2020, too late in the process.

<Zakim> chaals, you wanted to ask if there is anything to stop W3C actually doing it procedurally already

chaals: I wonder if it's possible to do this procedurally today. At what point does Director have right to push things to WD?

<plh> +1 to Florian

<dsinger_> (after Pierre I would like to focus on specific changes for P2020 in response to the specific issue filed)

florian: To the degree that Director can do anythng, they can, but there's no provision in the Process to do so. Can deny progress, but can't republish anything.

pal: Can't talk about bigger issue, but very specifically, want to focus on specific comment and suggestion
... Which was really to remove "on whether the specification would be appropriate as a W3C Specification"
... This is purely explanatory text
... To your exact point, criteria for CRs are not the criteria for REC
... It is now really confusing.
... And some specs could stay indefinitely in CR.
... I don't see what this clause adds, and think it's confusing.

<tantek> +1 to removing that clause. If process text doesn't serve a function, then it should be dropped

<jeff> Fantasai: It is there because it tells our expectation

<jeff> ... the spec should be at a state (tech reqts, etc.) that it could be a REC

<jeff> ... just lacking AC approval

<jeff> ... but it should be REC level quality

<tantek> disappointed in the scope creep in this issue

<jeff> PAL: We already have CR Criteria

<jeff> Fantasai: But it needs to be at a high quality

<jeff> PAL: That's implied by CR criteria

fantasai: CR shouldn't have lower quality in its drafting than a REC

<jeff> ... they already exist

pal: But isn't that implied by the criteria that already exist
... I don't see what that sentence helps

<Zakim> jeff, you wanted to respond to Chaals and to disagree with Florian

jeff: chaals was asking about whether some concerns could be addressed administratively
... the Director can put into a particular charter, if they want additional restrictions, that can be done

<Zakim> tantek, you wanted to oppose director/authority spec demotion

tantek: Wrt Director demoting the spec, it's out of scope for this issue.
... Wrt pal's point, I don't see this text as adding anything to the Process
... so suggest to drop it

<Zakim> dsinger_, you wanted to note that we don't say this in the definition of CR (alas)

tantek: and stop expanding the scope of this issue

dsinger_: Since it's not normative, fine to drop

<dsinger_> https://w3c.github.io/w3process/#maturity-levels

dsinger_: But I'm not seeing the same claim for quality in the definition of CR
... CR intro here say that it satisfies the technical requirements, but does not say that it should be at the level of quality of a REC

<plh> "Advancing to Candidate Recommendation indicates that the document is considered complete and fit for purpose" in the Note of the CR maturity level

<tantek> +1 on filing a separate issue

fantasai: Suggest to move the statement, not drop it.

florian: We have that statement in the definition of CR, but it's in a note.
... Maybe we just remove the statement from the intro and turn the note into not a note?

dsinger_: That note is perfect

pal: That note is good. I don't think it needs to be turned into anything else.

florian: Notes are nonbidning, not informative. If we remove the binding statement which is normative, then should replace by having note be normative.

pal: Agree with moving this explanation.
... But "well-written" is rather subjective.

florian: This is independent. Point is not only that we have to precisely define what's good enough to be a REC.
... but that whatever is good enough for REC, must be same level of quality for a CR aside from AC/implementation

pal: AC review can change a document

florian: When you go for an AC review, there may be issues filed. When we implement, may be issues filed. But in the absence of further comment, we're done.

<dsinger_> Suggested Change "This allows the entire W3C membership to provide feedback on whether the specification" to "This allows the entire W3C membership to provide feedback on the specification"; leave the Note as a Note for now; file an issue to clarify CR quality and maybe convert the Note into Normative text (for a future process).

florian: If you're not done, then you're nota at CR.

<tantek> +1 on dsinger's proposal

<plh> +1 to David proposal

fantasai: Not comfortable with what. Would like to capture the idea that in the absence of further feedback resulting in the need to change, a CR should be acceptable as a REC.
... It has to have that same level of quality, whatever that quality is.

plh: I like dsinger's proposal. Today Director approves CRs with editorial issues, etc.
... We do allow CRs that are not quite perfectly written as a REC.

<tantek> +1 plh this is a good point

plh: So putting text that we can't do that anymore
... would not be in favor.

<dsinger_> (I am not comfortable inventing normative text now; I would be fine elevating text)

tantek: agree with plh

pal: I'm personally comfortable with just remove that text and then actually taking time to define editorial reqs for a REC and CR, and move that to the next Process
... ...

<dsinger_> (I note that I can't find what the editorial requirements for a Rec are.)

florian: Want it to be clear that if you're in CR, and you have implementations, and no issues are filed, then you can go to REC.

pal: But it doesn't have a definition

florian: defining it to be the same still has a meaning

<inserted> fantasai notes that CSS sometimes uses this technique -- this undefined behavior over here, have to use the same behavior, whatever it is, over there

florian: Don't prefer dsinger's suggestion, but won't object

dsinger_: So proposal is remove the REC phrase from this intro sentence, , leave the note explaining the quality of a CR in the Process, and file an issue for next year clarifying the quality requirements for REC
... Note seems close enough

florian: That's why I'm not objecting

<tantek> yes the note is decent

<tantek> +1

<cwilso> +1

<plh> +1

<chaals> 0 #I share Florian's opinion I think…

RESOLUTION: Remove clause about " whether the specification is appropriate as a W3C Recommendation", file an issue on clarifying expectations in a future Process

<dsinger_> we agreed to Change "This allows the entire W3C membership to provide feedback on whether the specification" to "This allows the entire W3C membership to provide feedback on the specification"; leave the Note as a Note for now; file an issue to clarify CR and Rec quality and maybe convert the Note or parts of it into Normative text (for a future process).

Names for Proposed Changes under Patent Review

<dsinger_> Moving to #408 (https://github.com/w3c/w3process/issues/408)

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

<tantek> scribenick: tantek

fantasai: 408 introduces an amendment process for RECs
... so changes (in the document) can be reviewed, tested, commented on, revised etc., rather than sitting in a pull request, issue or errata document
... and we have a process where say these 5 of the 15 changes are ready and we want to fold them into the REC, then we issue a LC for those things
... and once there is approval from AC, no patent isssues, then we fold that into the spec
... seems like it would be easier to communicate if we had a name for the changes under review rather than all the changes
... candidate change for the changes in general, and proposed change for the ones that are going for AC review

(some informal back/forth about naming)

dsinger_: we don't have precise text edits yet

fantasai: if we agree conceptually we can draft text

dsinger_: at some point we might want to edit 6.1.4 errata management
... not a can of worms to open right now

<plh> [I still recommend to use P2019 instead of holding for revising RECs nowadays given our timeline. see https://github.com/w3c/geolocation-api/issues/42]

florian: agree on names for these would be good. these names not grown on my yet. nothing better to suggest

+1 accept concept, figure out names/text later

dsinger_: sounds like we are agreed conceptually but need wording
... ask editor to go back and write a pull request for this change?

fantasai: we should accept the names unless someone comes up with something better

dsinger_: the pull request should be atomic
... hearing silence consensus so the editor is instructed to come up with a pull request for this change, sooner rather than later

florian: yes it will be soon

dsinger_: this is the only pull request we expect to review in two weeks

scribe had audio drop out

dsinger_: ... comunity groups ...

fantasai: no

<inserted> florian: Resolve to defer latest two issues?

dsinger_: increasing turnout for AC ....
... editor are you clear?

florian: plural, but yes

dsinger_: jeff, what do you want?

jeff: AB needs to approve it, maybe thu july 2
... CG needs to approve anytime before july 2
... then we can send to ballot after AB approval

<chaals> [I would like to define CGs now but doubt we can and am OK with delaying it another year (it's only been a decade). I don't think there is a proposal we should act on in regards to #410 and am not convinced it is a problem we should solve]

jeff: AB won't want to send to membership unless patent policy is completed as well

wseltzer: still planning for the 30th

dsinger_: CG will take silence from PSIG on 403 as consent?

wseltzer: sure

dsinger_: next meeting 24th. AOB?
... ... finishing 4 min early!

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: i/David/General agreement that it's out of scope for 2020
FAILED: s/...God, help!//
Succeeded: s/thing/thing, just making CR better while spec is there/
Succeeded: i/florian/fantasai notes that CSS sometimes uses this technique -- this undefined behavior over here, have to use the same behavior, whatever it is, over there
Succeeded: s/and/, leave the note explaining the quality of a CR in the Process, and/
Succeeded: s/but not on names/but need wording/
Succeeded: i/dsinger/florian: Resolve to defer latest two issues?
Succeeded: s/you think PSIG will approve/CG will take silence from PSIG as consent/
Succeeded: s/silence from PSIG/silence from PSIG on 403/
Present: cwilso florian chaals wseltzer dsinger tantek jeff
Found ScribeNick: jeff
Found ScribeNick: fantasai
Found ScribeNick: tantek
Inferring Scribes: jeff, fantasai, tantek
Scribes: jeff, fantasai, tantek
ScribeNicks: jeff, fantasai, tantek

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)