<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
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
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
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).
<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.)[End of scribe.perl diagnostic output]