- From: Coralie Mercier <coralie@w3.org>
- Date: Wed, 27 Nov 2013 12:09:36 +0100
- To: "public-w3process@w3.org" <public-w3process@w3.org>
Dear all,
The minutes of the Chapter 7 Revisions (part of Advisory Board f2f Day 2)
meeting of 15 November 2013 are available:
https://www.w3.org/2013/11/15-w3process-minutes.html
A text snapshot follows; the summary per topic is included in the
"Contents" section.
Cheers,
Coralie
==================================================================
Chapter 7 Revisions (part of Advisory Board f2f Day 2)
15 Nov 2013
These minutes are public. Some links may be visible only to the
W3C Advisory Board.
See also: [2]IRC log
[2] http://www.w3.org/2013/11/15-w3process-irc
Attendees
Present
Jean-Charles Verdié, Jeff Jaffe, Jim Bell, Ian Jacobs,
Charles McCathie Nevile, Steve Holbrook, Mike Champion,
Qiuling Pan, Ralph Swick, Coralie Mercier (scribe), Ann
Bassetti, Chris Wilson (phone), fantasai
Regrets
Tantek Çelik
Chair
Steve Zilles
Scribe
Ian Jacobs, Coralie Mercier
Contents and summary
* [3]Topics
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:
+ For horizontal review of specs: It was proposed that
WAI PF develop a best practices doc for how to work
with that group.
+ To enter LCCR: 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.
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:
+ Removing "how" from pubrules
+ Having clearer top of document
+ Having machine-processable information
* [4]Summary of Action Items
__________________________________________________________
<scribe> scribe: Ian
<scribe> scribenick: Ian
<SteveZ> [5]http://www.w3.org/2013/11/13-w3process-minutes.html
[5] 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> [6]notes from Wednesday's Process breakout
[6] http://www.w3.org/2013/11/13-w3process-minutes.html
<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>
[7]https://www.w3.org/community/w3process/track/issues/52
[7] 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> [8]IETF Standards Process
[8] http://www.ietf.org/about/standards-process.html
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
[9]http://www.w3.org/2013/11/15-w3process-minutes.html#action01
]
[9] 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
[10]http://www.w3.org/2013/11/15-w3process-minutes.html#action0
2]
[10] 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'
Summary of Action Items
[NEW] 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
[11]http://www.w3.org/2013/11/15-w3process-minutes.html#action0
2]
[NEW] ACTION: Charles to update the draft to make a distinction
between publication and process state changes [recorded in
[12]http://www.w3.org/2013/11/15-w3process-minutes.html#action0
1]
[11] http://www.w3.org/2013/11/15-w3process-minutes.html#action02
[12] http://www.w3.org/2013/11/15-w3process-minutes.html#action01
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [13]scribe.perl version
1.138 ([14]CVS log)
$Date: 2013-11-27 11:06:34 $
[13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[14] http://dev.w3.org/cvsweb/2002/scribe/
--
Coralie Mercier - W3C Communications Team - http://www.w3.org
mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/
Received on Wednesday, 27 November 2013 11:09:46 UTC