These minutes are public. Some links may be visible only to the W3C Advisory Board.
See also: IRC log
There was a Technical Plenary breakout session in which is was suggested to call LCCR "Candidate Recommendation”. This name maps to the patent policy according to PSIG. There was no consensus in the breakout to call a Recommendation a Standard.
The Advisory Board took a RESOLUTION: LCCR is now Candidate Recommendation.
The AB discussed several aspects of signalling:
Charles McCathie Nevile took the action to ensure that the process keeps it clear that the exclusion clock is restarted as needed with new LCCR, and that it is possible to produce a new LCCR for changes without arbitrary overhead.
Elika Etemad (fantasai), who joined the AB for this discussion, showed a draft revised layout for specifications, including a clearer Status of the Document.
The Advisory Board expressed strong support for:
<scribe> scribe: Ian
<scribe> scribenick: Ian
<SteveZ> http://www.w3.org/2013/11/13-w3process-minutes.html
SZ: Those are minutes from Weds breakout
session
... Here's a summary of some interesting comments:
1) Observation by Paul Cotton that the existing process says that LC is mandatory and CR is optional. And our proposal flips that...and in doing so it seems to solve a number of problems.
2) We also discussed issue 39 (transition to the new process). There was basically agreement with the series of memos that said (1) new work should use new process (2) for existing work, groups can choose when to switch (3) not good idea to switch if mid last call (4) should be some time after which group must switch
3) We also talked about CSS WG current approaches (e.g., different phases "exploring," "resolving," and "refining")
SZ: in the last phase you have most of the details and are looking for review to catch final details
Jeff: How does prefixing work in that model?
SZ: Prefixing is used up to CR. You start using it whenever people start implementing.
<koalie> [Mike Champion arrives]
<Ralph> notes from Wednesday's Process breakout
<cwilso> e.g. features only show up in Canary until they're mostly solid.
SteveZ: I mention the three phases as one example
of how to label parts of a document and what type of review is sought
... both Paul Cotton and David Singer said that having a signal that a spec is
in a state for review is important. The label doesn't matter as much, but the
signal is important.
Jeff: Do they want a paragraph in chapter 7 that formalizes an optional signal?
SteveZ: Could be in process or in pubrules.
Jeff: So we need to think about how we do that.
4) Regarding status names, the name change to "Recommendation" to "Standard" got some support but also strong opposition
Mike: The reason I object to that is that I want to reserve "standard" for a hypothetical future state like the IETF uses.
Steve: I propose we come back to this
discussion
... regarding proposal to change LCCR, most support was for Candidate
Recommendation, but not unanimity
SZ: I observe that we split LC into two pieces - IPR review and wide technical review. We let wide tech review happen without a transitional state and the new process is mostly an IPR transition signal
SteveZ: In IETF, "Proposed Standard" is deemed suitable for normative reference.
<SteveZ> https://www.w3.org/community/w3process/track/issues/52
Steve: We need to decide whether we want a label, where to put the info about the label, and what the label is.
Jeff: I'm not sure that we want to create a label. But if we do we still to discuss what goes with it like communication, minimum duration
SZ: I want to avoid introducing a new state...just a label that is descriptive about a WD.
Mike: From a UI perspective...imagine WDs say
"Draft". But drafts that trigger an exclusion opportunity should be very
explicit that there is one (and until date)
... and those that want wide review should say that.
... people don't want to move backward in process
... from a user perspective, that's what I'd like to see.
<Ralph> IETF Standards Process
IJ: Sounds like Ian's last year's process proposal
SZ: We want signals one what the WG wants.
IJ: I think status sections are largely designed for that; but we know people say they are not read, so we need to do better in UI
Mike: The bits that I am interested in
communicating clearly are: wide review, exclusion opportunity, implementation
feedback request
... those should be decoupled from maturity level since different parts of the
specification may be differently mature
... I'm talking about attributes (not state changes)
<Zakim> chaals, you wanted to talk about setting review expectations
Chaals: what the proposal does at the moment is
set requiremnets and expectations. There are two stages when you have exclusion
opportunities (FPWD, LCCR)
... I believe that satisfies what you are looking for.
... getting into LCCR is sufficiently painful for all concerned that you are
encouraged not to do it often
<koalie> [Fantasai enters]
Chaals: ArtB wondered why this was so difficult.
<inserted> Chaals: the answer is that if you request a fourth CR, the director will probably be more reluctant to meet with you if you don't have a convincing argument that *this time* you're really ready
Chaals: Maybe we should be more explicit about
why we are encouraging review
... we could be more explicit that the changes that are important are those
that should be reviewed
fantasai: In CSS WG, we consider WD a design phase. When we need implementation we put it in CR. When we have gotten the 2 interop implementations, we move to rec. That CR phase does involve review of changes and revisions. You are asking in the proposed process to put implementation experience in the draft status.
Jeff: Why are multiple CRs discouraged more in
the new process than in the old process?
... I'm understanding how the new process does not fix a particular problem we
have at the moment.
fantasai: I disagree with a goal I heard Charles express.
Charles: I don't think it's a position I hold.
fantasai: I want to be able to make changes to a CR because I want people to still know it's for implementation
<koalie> scribenick: koalie
Ian: My understanding is there is no backward in
the new process
... you repeat a label
... editorial changes allow you to request to go forward
... I heard fantasai hear the CSS WG wants a signal "we're done"
... you had two in the current process and now you have one and you intend to
use it for REC
<IanJ> [Discussion of whether new process is designed to discourage multiple LCCRs]
<scribe> scribenick: IanJ
Jeff: you are using LCCR and based on usage you
are making editorial and minor changes, it should be fine.
... if you are making substantive changes, my impression is both in the new
and old process you would be doing multiple CRs (so it's not a change, and it
has never been encouraged)
<Zakim> chaals, you wanted to suggest that the process doesn't encourage implementation before or after CR, but makes it easier to support those groups who do implementation early.
<koalie> fantasai: I do not agree with chaals' implication that publishing more than one LCCR is wrong
chaals: fantasai has correctly called out that
there are people who use CR to get implementation. The new process was not
designed to stop people from doing that.
... there reason for discouraging multiple CR drafts is repeating exclusion
opportunity is somewhat painful
Charles: Perhaps we should look at proposed
changes to a CR
... so you can publish a public draft of an edited CR for review, before
calling the next exclusion opportunity.
... There is a goal to start to get implementations early in the process.
... sometimes late. The process needs to support both.
fantasai: The point about calls for exclusions is
an important one.
... we want to make changes without triggering CFE over the whole spec.
Charles: You don't over the whole spec; it's just over the delta.
IJ: Current process distinguishes process transitions and doc status labels
Charles: The proposal notes that the way you go through these stages is to go through the Director.
[IJ: another way to characterize it is that the Director is for state changes, not publications as it were]
<fantasai> WD phase has section "To publish a revised Working draft", no such section for CR
Charles: There is no requirement for formal review when you do the publication.
[We discuss "publication" v. "director approval" v. "meeting with the director"]
SteveZ: The Director may not require a meeting;
may simply approve a request.
... the point of this getting the ok is that substantive changes may be
affecting implementations
Charles: What it does is trigger an exclusion opportunity.
fantasai: There's some overlap between concepts
of substantive and non-substantive before and after Rec.
... I think it would be useful to define one in terms of the other....
... If the AB agrees that changes in classes 1 and 2 are ok to do without
going through LCCR and 3 and 4, then I'm satisfied and can work with Charles to
make it clear.
Charles: I think it should be made clearer
[IJ: we also said we did not want to change language from current process...so we need to be aware of that]
SteveZ: We'll add this to the issues list
... Judy raised a question on signaling.
... Judy is concerned about horizontal review of specifications; horz groups
are resource constrained but seek to establish individual relationships to each
group
... my suggestion to Judy was that WAI PF develop a best practices doc for how
to work with that group, and to use that as a starting point for how to work
with the WGs
... so this would not require a change to the process but would help horz
review groups document how best to interact with them
... the other piece of the story is that you need wide review to enter LCCR.
It becomes the responsibility of the Director to confirm wide review
requirement has been met (or reject requests where that has not happened)
<Ralph> SteveZ: i.e. it is the responsibility of the WG to show they have met the wide review requirement rather than the responsibility of the horizontal review groups to show they have _not_ met the requirement
Steve: I think all parties will need to execute on the process as prescribed.
fantasai: I spoke with Judy as well; seems like a good side effect of this process proposal - encourages better interactions
<Ralph> s/Elika/fantasai/G
Mike: Let's signal functionally complete à la
Ian's proposal to indicate clearly what the group wants
... these are attribute signals, not process signals.
... I want groups to be able to say clearly "we think we are functionaly
complete" but we not overload process states with this
Ralph: I'm comfortable with the notion of
attributes rather than process states, as long as we have a way to document
which attributes are in which state.
... The notion of explaining to non-participants what the story is, and what
the group wants, and maturity labels, and status, they are all connected
things.
... Group is obligated to state substantive changes to start exclusion clock,
but it's not clear to me that the Director has to confirm.
SteveZ: Ian disconnected publication from
process, but the doc conflates them and that may be creating confusion.
... we've identified this as a bug.
Ralph: Right, we tried to make this even easier.
<fantasai> My understanding is that Class1&2 changes can just republish, wherease class3&4 changes require re-entry procedures for LCCR
<fantasai> Ralph is saying that in the first case, shouldn't set exclusion clock (unless someone later objects that it should have been reset and makes a case for that)
<scribe> ACTION: Charles to update the draft to make a distinction between publication and process state changes [recorded in http://www.w3.org/2013/11/15-w3process-minutes.html#action01]
<trackbot> Created ACTION-17 - Update the draft to make a distinction between publication and process state changes [on Charles McCathie Nevile - due 2013-11-22].
<fantasai> and that the second case does reset the clock
Jeff: Summary of what we are trying to get done. We have an AB task force that meets weekly to look at the changes. As an important member of the community, it would be good if you could join the task force (or at least follow the public list)
<Ralph> Ralph: in the clarifications Chaals and Fantasai will do, the action that starts a new exclusion clock should be explicitly linked so that if the words "Last Call" are subsequently dropped, the points at which the clock starts remain clear
Jeff: I think you are giving us good input.
<chaals> ACTION: chaals to ensure that the process keeps it clear that the exclusion clock is restarted as needed with new LCCR, and that it is possible to produce a new LCCR for changes without arbitrary overhead [recorded in http://www.w3.org/2013/11/15-w3process-minutes.html#action02]
<trackbot> Created ACTION-18 - Ensure that the process keeps it clear that the exclusion clock is restarted as needed with new lccr, and that it is possible to produce a new lccr for changes without arbitrary overhead [on Charles McCathie Nevile - due 2013-11-22].
Fantasai: I'm happy to join the task force
<Ralph> action-18: restart the exclusion clock only as needed, when the WG publishes a new [CR] document version stating that there have been substantive changes
<trackbot> Notes added to action-18 Ensure that the process keeps it clear that the exclusion clock is restarted as needed with new lccr, and that it is possible to produce a new lccr for changes without arbitrary overhead.
<chaals> [I had added myself to the queue to point out that one concern Judy raised was that review requires coordinating schedules, which is not really easy, but this process doesn't really help that, it just puts a burden on the Working Group to ensure they did coordinate with the review groups]
<chaals> [Actually, I do read the Status sections, and get frustrated at editors who don't actually bother putting the useful status into it. But I still like the sense of Fantasai's proposal]
<Ralph> Ian: the rationale for the status to be in a particular place was so that the World knew where to look
<Ralph> ... as long as there is a "well understood" place
IJ: Strong support for:
... - Removing "how" from pubrules
... - Having clearer top of document
... - Having machine-processable information
Ralph: Yes, there's some compromise language
... it's important that people know how to find the information; e.g. "status
information must be readily accessible"
Ann: Print is still important
<Zakim> Ralph, you wanted to heap praise on Fantasai
Fantasai: Agreed; and we can work on that.
<jcverdie_> [+1 to fantasai's proposal, love it, just needs addition of status info imho]
<Ralph> Ann: make sure critical bits appear in the Print version
SteveZ: There seems to be general agreement that
we should put the doc requirements on the document, not the particular section
("the status section")
... and implementation is left to pubrules and UI
Charles: Proposed s/Status Section/Status information/
Fantasai: Ok with that
SteveZ: Can we resolve to change LCCR to Candidate Rec?
IJ: Yes, if we can change Rec to Standard independently.
SteveZ: Yes
RESOLUTION: LCCR is now Candidate Recommendation
<cwilso> 15 minute break? Are we moving back to #ab?
<koalie> cwilso, we're breaking in 15'