See also: IRC log
<SteveZ> Agenda: 1. Review Open Action Items https://www.w3.org/community/w3process/track/actions/open 2. Issue-141: Improve Errata management in W3C This is a relatively narrow issue. For reasons of process and practice, W3C working groups do not necessarily issue errata in an expeditious fashion. We should fix the W3C Process so that it encourages groups to consistently and expeditiously issue errata. There are other related topics, such as where the errata sh[CUT]
<scribe> Scribe: fantasai
jeff: Wrt living standards, one
of the things hixie has regularly raised, a fair issue, is that
standards developed through W3C Process tend to get out of date
because Web tech is a living technology and things get changed
almost daily.
... That's a problem for the approach that we have.
... In my mind, fact that there are constant changes fall into
a few buckets.
... One bucket is "here's a new feature".
... In my mind, that's not errata, that's different.
... Just need to move from levels faster
<SteveZ> RESOLVED: Close Action 26 as completed by message http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0133.html
jeff: Also changes faster that
are more fairly called errata
... tweaks or slight enhancements or corrections
... for things that in the spec
... My impression is that the critique on how WGs handle errata
is correct
... It's not done frequently enough
... Charles comments in his email is that WGs should do things
more regularly, Process is not the right place. Can't write
rules that ensure ppl work hard.
... I disagree with that.
... It is an issue about what WGs should do more
regularly
... We should enhance the process to make sure we have more
consistent focus on this
... For example, a potential solution for WGs who have already
reduced specs and are still in operation
... than for WGs that have terminated
... For active WGs, you could put in a requirement that they
put in a quarterly or monthly call for errata
... To make sure that this is done as expeditiously as
possible
... I don't know whether monthly or quarterly is possible
... But would like to offer that for this CG to discuss
<jeff> Fantasai: In my experience there are several problems
<jeff> ... Biggest: They are in a separate physical document.
<jeff> ... so they are not noticed by people
<jeff> ... they are not in the spec because they have not gone through testing, AC review, etc.
<jeff> ... so they are not REC level
<jeff> ... so the spec is out of date.
<jeff> ... solution needs to be to fold errata into document
<jeff> ... so uptodate spec can be published regularly
<jeff> ... if REC process is needed, we can distinguish errata from actual text
<jeff> ... To meet both requirements, should have updated REC with diff marks
<jeff> ... "we want to make these changes but not gone through entire process"
<jeff> ... need disposition of comments, etc., as well
<jeff> ... need those actually in document.
<jeff> ... then they are more maintainable and more usable by readers
<jeff> ... alternatively can fold in changes and make separate list of what the changes are
<jeff> ... or allow WG to use both (folded in when they decide; a list before they decide)
<jeff> ... this is why CSS 2.1 has not been published
<jeff> ... ED more up to date
<Mike> +1 to most of what Elika said, especially about gettig errata folded in regularly / expeditiously
<jeff> ... make tests, implementation reports
<jeff> ... which we should do anyway - but long cycle
<jeff> ... need to wait for implementation
<jeff> ... but can't publish new draft due to REC hurdle.
<jeff> ... Example:
http://www.w3.org/TR/css-flexbox-1/#changes
<jeff> ... Folded in all changes (since CR document)
<jeff> ... have a list of changes
<jeff> ... this would give us an update of the spec right in the document
<jeff> ... would still need implementations, etc.
jeff: I like fantasai's
idea
... Different than what I was thinking about
... I want to be very careful about how we implement fantasai's
idea
... Idea I was mentioning
... [..] was a quick bandaid we could get in time for 2015
version of process
... If we could get fantasai's idea in as well, that would be
fantastic
... want to be a little bit careful
... I'm not sure that the terms are sufficiently
well-defined
... If we take the current spec, and we start amending it with
all of our new ideas
... not just the errata
... then of course we've moved into a full living standard
model
... which is kindof okay
... but we just have to know what we're doing
... and how it's working
... So if I have a CSS3 module that has gone to REC
... then I start working on CSS4 module
... then simultaneously I'm enhancing the CSS3 module with
errata
... but also I'm putting new ideas into CSS3
fantasai: I was talking only about actual errata
jeff: start to talk about errata,
but talk about changes
... concerned that bleeding from errata to any kind of
changes
... do chairs and wgs, are they sufficiently clear on the
differences between the two that we can bring them so closely
together?
... Are we sure that ppl won't bleed broader changes into the
draft?
Mike: I agree with a lot of what
fantasai and jeff said
... Think it's very important to get something about errata
into the 2015 Process document
... Clearly there does get tangled up with larger issue of
living standards
... Important to distinguish errata, which fold into published
spec regularly and frequently
... that are outright errors, that couldn't logically change
WGs or Directors decisions -- things that could confuse
implementers
... I think that is what we need to clearly and quickly
fix
... Some exhortation that a WG needs to make this a high
priority, and if they don't do it they risk losing the charter
to own that space
... The other category we have to distinguish is errors in the
original spec, but second thoughts ppl have esp. as they
implement
... Hixie's model is that if the impls move in a different way
than the spec anticipated, then spec should change to match
implementations
... I'm not ready to go there yet
... We need to make it hard to say that we should've done it
differently
... There are a lot of ppl, implementations aren't coming out
every weeks, that are following spec as written
... W3C should issue REC as written, should be the right way to
do it unless there is compelling evidence to the
contrary.
... Changes that sensible ppl would agree are errors
... New interpretations should be candidates for next
revision
... And then new features
... Should clearly separate errors from new stuff
... Should think about how to handle living standards, taking
feedback from community
... If implementor says spec isn't right way to do it
<Zakim> fantasai, you wanted to answer that and to
<jeff> fantasai: In terms of Jeff's question - broader changes into text
<jeff> ... CSS is pretty clear about what is a new feature
<jeff> ... CSS fixes both clear errors and information from implementations
<jeff> ... In the latter case, CSS has a long discussion with implementors
<jeff> ... Could be spec is right; implementors are right; or a third solution.
<jeff> ... If we have a conformant implementation of a Level 2 and a Level 3 spec, they should agree on the features they both support
<jeff> ... If we add new features to L3, we won't backport to 2.1
<jeff> ... If in L3 we clarify things from 2.1 - we backport it into 2.1.
<jeff> ... helps L3, L2 interop
<Zakim> timeless, you wanted to note that Acid3 wagged the dog and we eventually unwagged the dog
timeless: hixie made a claim that
no, we just always adapt what implementations do
... but that's not actually true.
... Acid3 had a bug, and implementors all changed to match the
test
... So spec changed to match implementers
... But then ppl were all like, this is wrong
... so spec changed back
... So it's not always the case that hixie's spec copies state
of implementations
<SteveZ> 7.7.1 Errata Management Tracking errors is an important part of a Working Group's ongoing care of a Recommendation; for this reason, the scope of a Working Group charter generally allows time for work after publication of a Recommendation. In this Process Document, the term "erratum" (plural "errata") refers to any class of mistake, from mere editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g[CUT]
SteveZ: Want to note what the
document already says today [paste]
... It does say that WGs MUST track errata on an errata
page
... So there is a MUST
... I think Jeff's point, that we began the discussion with,
that needs clarification on how frequently
... etc.
... Second point we've had in this dicussion is that errata is
not new features
... That's important because the patent, PSIG, and FAQ say that
maintenance -- anything other than adding new features -- can
be done without changing the patent commitments
... fantasai and Jeff have also said it, boundary between new
features and other changes is the boundary of errata vs new
version
... Lastly, the current definition sortof talks about an errata
page, which is why we do it the way we do it
... That's getting in the way
... So that paragraph should be modified to allow more
flexibility in the way that errata are handled
... So that we can experiment with the kinds of things fantasai
was talking about
... Process should say what errata are, how frequently they are
maintained, and that they are appropriately connected to the
appropriate sections of the spec
<Zakim> timeless, you wanted to note that i sent feedback on the spec asking about when a WG ceases to exist, who is responsible for tracking errata
<Zakim> jeff, you wanted to agree that errata should not include new features, but the process document doesn't seem to say it
jeff: Interesting quoted the
Process document on errata
... Interesting that you commented that we all agree on what
constitues errata
... E.g. Process says errata could include serious error that
could affect conformance
... So I'm clarifying difference between error and new
feature
... At least to say that correcting error is fine, but new
features not
<Zakim> jj, you wanted to talk about PubRules
jeff: I also noticed that when
fantasai was talking about more user-friendly errat
page...
... Reference here to pubrules
... As we entertain fantasai's change, have to include Ian and
Ted and other ppl who watch over pubrules
... Don't think they'd have a reason to dislike her proposal,
but need to include them in discussion
SteveZ: In Section 7 we define a
category of changes
... The third category allows things that can change
conformance, but not new features
... There's 2 kinds of substanive
<jeff> http://www.w3.org/2014/Process-20140801/#substantive-change
SteveZ: First kind was an errata, second kind wasn't
jeff: So, you're saying this is
already particularly clear
... Since we don't have a problem with any of the first 3 types
of changes under errata, not #4
... If that's the intent, then I guess we could just make it
explicit by referring back to this section
SteveZ: That's exactly what I was
saying
... So somebody should redraft Section 7.7.1
jeff: Charles said he would update the spec based on the minutes
SteveZ: First thing is, we would
like to change the MUST do errata to MUST do errata on a timely
basis
... Jeff, you asked that it be a regular activity of the WG
<Mike> What does "regular" mean? once a year minimum?
jeff: For WGs that are responsible, they should have a call for errata, and maybe quarterly makes sense
SteveZ: I think more frequently makes sense, but quarterly is better than never
<Mike> Quarterly is good!
SteveZ: Let's suggest that MUST
consider updating errata on a quarterly basis
... Any objection to that?
<jeff> fantasai: Quarterly is fine if there is a reasonable way to update
timeless: Text should encourage more frequently than quarterly
SteveZ: "should be no less
frequently than"
... Second point was that text should be clarified to say that
kinds of changes that are errata are the first 3 categories of
changes, not #4 (new features)
... Third change is, with the cooperation of the people that do
pubrules, the reference to how errata are expressed should be
updated to allow experimentation with inline errata
<Zakim> timeless, you wanted to note that we should refer by reference-tag and not by dotted-number and to ask about who manages errata when no WG exists w/ managing it in the charter
<Zakim> timeless, you wanted to ask about who manages errata when no WG exists w/ managing it in the charter
fantasai: i think you just need to say that errata should be part of the document, but called out so that it's clear what is in REC and what has yet to complete process to REC
timeless asks about RECs that are no longer actively developed by a WG
SteveZ: I think the idea is to
create WGs to maintain REC
... although it might be difficult to staff such a WG
... Decided to only tackle active WGs for now, since easier
jeff: For the record, while I
agree with timeless's point, I'd rather apply the 80/20
rule
... If I address this only for the supergroups, I'd be pretty
happy camper
... Though wouldn't be disappointed if someone came up with a
solution for the other 20%!
... Wrt folding errata into the document
... Before updating Process document with fantasai's idea, we
should write it up separately and cleanly
... And get pubrules team's reaction first.
SteveZ: Just need someone to write it up
jeff: Really like fantasai's
first idea a lot
... I'd like to get that as a compact, self-contained
proposal
... Run it by pubrules, and if ppl generally comfortable, plug
it in
ACTION fantasai to write up proposal for inline errata
<trackbot> Created ACTION-35 - Write up proposal for inline errata [on Elika Etemad - due 2014-10-21].
SteveZ: Okay, 5min left
... I think that covers most of what we discussed on item
141
... made good progress
... Would like to have short overview of wide review
discussion
... It got locked in on small piece of discussion before ready
to do that
... That's why I forwarded fantasai's notes to the distribution
list
... Art had done a CFC for creation of a mailing list
... I think comments on mailing list are useful
... I think it's focused too much on one way that might be
useful that wide review has occurred
... My concern is that we not get locked into a particular
solution, with assumption that if you did that you necessarily
met wide review
... That was not the intent of the wide review requirement, and
other methods of meeting wide review should be allowed
... I think ? ... team looking for wide review
... E.g. if you had comments coming from many places, then good
indication of wide review
... Comments only from implementors, indicates not wide
review
... Think we need a longer discussion before deciding what to
do about things
... With that intor would be glad to hear from others
<Zakim> jeff, you wanted to express the frustrations of Chairs
jeff: I think that we have to differentiate between theory space and practice space
<timeless> i/Errata Management Tracking/topic: Adjusting Errata Management Tracking section of process/
jeff: From theory space, what's
currently in document is great, and certainly gives all
flexibility you need to achieve diverse means of wide
review
... I think what chairs are saying is that newfangled process,
don't make my life harder
... As I try to implement it, you've made my life harder, I
used to know how to get wide review, it was LCWD, now what do I
do
... Give me the simple approach.
... I may not do it exactly that way, but I want one way to go
and do it and i know I'm done
... Art's proposal was to have one way that it could get
done
... Not to require that it be done that way, but demonstrate
that it can be done, can be done easily, could also be done
other ways
... I think having in Process 2015 a safe harbor approach, if
you do this, you're done, that's a good idea
SteveZ: Whole intent of wide review definition was to *not* have a safe harbor approach, because that wasn't leading to good wide reviews
<timeless> s|i/wanted to talk about PubRules/Topic: PubRules/||
SteveZ: That's my main concern, they'll think "if I do this I'm done", no you're not done. That's the key point
jeff: Then I invite you to come
to Chairs Breakfast Tuesday at TPAC
... We need more dialog
SteveZ: I accept your
invitation
... Also suggest having a breakout on wide review during
breakout period
... As a separate topic
... My intent is also have breakout on Proces 2015
... 2 breakouts
<jeff> http://www.w3.org/2014/11/TPAC/
SteveZ: Thanks everyone. Will
continue next week
... Week after is TPAC
... Anything else?
... Meeting adjourned.
<timeless> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/happen today/in the spec/ Succeeded: s/Who is ??P4// Succeeded: s/decisions/decisions -- things that could confuse implementers/ Succeeded: s/;/:/ Succeeded: s/longer/less frequently/ Succeeded: s/teams'/team's/ Succeeded: i/Review Open Action/topic: Agenda Succeeded: i/Wrt living standards/topic: Integrating Feedback Succeeded: s/1+// Succeeded: s/sorry// FAILED: i/Errata Management Tracking/topic: Adjusting Errata Management Tracking section of process Succeeded: i/wanted to talk about PubRules/Topic: PubRules Succeeded: s/approche/approach/ FAILED: s|i/wanted to talk about PubRules/Topic: PubRules/|| Succeeded: i/wanted to talk about PubRules/Topic: PubRules Succeeded: i/7.7.1 Errata/topic: Adjusting Errata Management Tracking section of process Succeeded: s/+1.416.481.aaaa// Succeeded: s/, ,/,/ Found Scribe: fantasai Inferring ScribeNick: fantasai Default Present: SteveZ, Jay, Mike_Champion, Fantasai, Jeff, timeless, Keio Present: SteveZ Jay Mike_Champion Fantasai Jeff timeless Keio Regrets: chaals Got date from IRC log name: 14 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/14-w3process-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]