Draft Minutes of 14 Octobe Process TF Telcon

All,
To get the information out, I am distributing the link to the (unedited) minutes from this morning's Telcon. Apologies to the participants for any misstatements.
http://www.w3.org/2014/10/14-w3process-minutes.html


[W3C]<http://www.w3.org/>

- DRAFT -
Revising W3C Process Community Group Teleconference
14 Oct 2014

See also: IRC log<http://www.w3.org/2014/10/14-w3process-irc>

Attendees
Present: Jay, SteveZ, Fantasai, Mike Champion, Jeff, timeless
Regrets
Chair
SteveZ
Scribe
fantasai
Contents

  *   Topics<http://www.w3.org/2014/10/14-w3process-minutes.html#agenda>
     *   Agenda<http://www.w3.org/2014/10/14-w3process-minutes.html#item01>
     *   Integrating Feedback<http://www.w3.org/2014/10/14-w3process-minutes.html#item02>
     *   Adjusting Errata Management Tracking section of process<http://www.w3.org/2014/10/14-w3process-minutes.html#item03>
     *   PubRules<http://www.w3.org/2014/10/14-w3process-minutes.html#item04>
  *   Summary of Action Items<http://www.w3.org/2014/10/14-w3process-minutes.html#ActionSummary>

________________________________
Agenda

<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

Integrating Feedback

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

Adjusting Errata Management Tracking section of process

<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

PubRules

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

Summary of Action Items
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.138 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-10-14 15:02:13 $
________________________________

Present: Fantasai Jay Keio Mike_Champion SteveZ jeff timeless



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: