Chapter 7 Revisions (part of Advisory Board f2f Day 2)
15 Nov 2013

<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'