Revising W3C Process Community Group Teleconference -- 20 Jan 2015

<trackbot> Date: 20 January 2015

<scribe> scribenick: jeff

Open Action Items

Steve: Action 46 belonging to DS
... believe it was done.

<SteveZ> Close Action-46 Consider proposing minimal changes to the nov errata revision to address concerns

<dsinger> yes, I suggested such minimal changes. I am not sure Chaals agrees with them, and had hoped to cover that also.

<chaals> [David did send a reply]

Issue-141 Errata management

<chaals> close action-46

<trackbot> Closed action-46.

SZ: I sent a message yesterday
... pull out separate issues in discussion of 141
... Issue #1: Original issue
... Issue #2: Can RECs be updated in place
... Issue #3: Are there 2 separate processes; one for errata and one for new features?
... propose to treat independently
... Consensus that we can ask groups to be more responsive
... Chaals felt that current requirement to demonstrate that errata have been widely reviewed as part of publishing a revised Recommendation was adequate
... I feel must be more frequent
... but Chaals was only objector

CMN: Repeat? Doesn't match reality.

SZ: Because wide review is only at CR.

CMN: No, wide review happens throughout.

SZ: Only demonstrated at CR.

CMN: But need to do throughout to get to CR.

SZ: On second issue, I propose to open another action
... Can live with David Singer's suggested text
... not that I or Elika like it - but it is an improvement

CMN: I object to some of David's text, but it can be an improvement.

Jeff: Let's focus on Issue #1.

SZ: But since November Issue #2 has been part of the resolution of Issue-141.

<chaals> [I wrote my specific objections in reply to your proposal David. A couple of points, plus the fact that the change was minimal, i.e. maintaining maximal verbosity…]

SZ: and David's is an improvement over current text (although it does not go as far as Elika's)

[Jeff clarifies that Issue #2 was not whether RECs can be updated in place, but whether a document can exist with Errata text + REC text]

[Steve looks for David's proposal]

<SteveZ> David's proposed text related to Issue 2 of my 3 issues: Working groups may decide how to document errata. Examples of acceptable errata management include an errata page, possibly auto-generated from a database, or a document that identifies itself as based on the Recommendation text and clearly identifies the errata and any proposed corrections.

Jeff: I believe that David and I agreed that the latter approach could be identified as a best practice.

SZ: Could be. I saw parts of that discussion.
... Yup, I now verify that DS said OK to that.
... Jeff, make a suggestion of wording.

Jeff: The editor is really good at that.

<dsinger> change second sentence: The best practice is a document that identifies itself as based on the Recommendation text and clearly identifies the errata and any proposed corrections; other approaches include various forms of an errata page, possibly auto-generated from a database.

Jeff: being faithful to DS's intent - and figuring out the right flow to insert the words "best practice"

<SteveZ> Jeff's request that was agreed to by David is: One item that I emphasized in my version is that the document that bases on REC text and clearly identifies proposed corrections should be identified as a best practice.

Jeff: Look at David's compilation above.

SZ: I agree. David's sentence captures what we wanted to do
... OK,, Chaals?

<dsinger> oops, should add “It is also a best practice to alert readers of the recommendation to the existence of the errata, via a statement and link in the header of the recommendation"?

CMN: Yeah.

SZ: Third issue. I would like to make it a separate issue and add it to our queue.
... Mixed feelings - two separate docs is an annoyance
... Waiting for new features is not practical.

<chaals> RESOLUTION: Incorporate David Singer's text for issue-141

SZ: more discussion is needed to resolve that.
... We always had a separation between errata and new work
... recommend postpone Issue #3

Jeff: We could point out that for Docs that get new releases in less than a year, the need for Errata is attenuated compared to docs that take years to get from release to release

SZ: Problem is that people's expectations don't meet reality.

CMN: There is nothing in the current requirement which says Errata cannot be tracked by publishing a draft revision of the document, such as an editor's draft

<dsinger> issue 3: can the WG put new features and errata into the same document? do we need to say anything? clearly the approval needed for a document is the heaviest one related to the changes, so if you mix, you have to do ‘revised rec’ approval, if you have just errata, you have ‘edited rec’ approval (which is lighter). is this not obvious?

CMN: If people are going slowly in specs, we can't change in process
... process asks issues to be done in timely fashion - not all groups do that.
... we can ask people to show errata in Editor's draft.
... Can do that happily in existing process
... My objection had been enforcing a system that makes it impossible.
... Some groups update frequently
... Let's not get in their way

SZ: Agreed.
... David's suggestion I believe addresses your concerns.
... You can do what you would like.

CMN: I think so.
... ta ta ta ta ta
... I believe David's suggestion addresses most of my concerns
... but it is not in front of me
... looking for it

<SteveZ> David's full, unmodified proposal is at: http://lists.w3.org/Archives/Public/public-w3process/2015Jan/0038.html

CMN: No, I still object to the definition of errata
... needless distinction between what I do for errata and what I do for everything else.
... David says we can use this for other purposes
... won't be read that way
... people will interpret it in most bureaucractic way

SZ: Let's note your concern but move forward with David's text.

CMN: WFM

MC: That is the nub of the issue.
... Some changes (errata) can be made in place with no PP implications.
... Don't need Revised REC process.
... not needed for typos

<dsinger> I sent revised text to the reflector just now.

MC: Remember: Root issue is the claim (some credibility) that our DOCs have errors and are out of date within weeks of pubs
... and we are doing nothing
... real changes require more handling
... but let's address easy stuff easily.

SZ: This is suitable for Issue-152.

MC: Thanks, Steve.

<dsinger> I think the issue with allowing edits with no review is when someone disagrees whether they have PP implications. Minimal review allows an AC rep to say “sorry, you just entangled the infamous Mordred patent, which the WG was careful to avoid in the Rec”

CMN: When people complain about our mistakes - these are not typos
... implementors changed their mind or the spec is ambiguous
... resolving requires a substantive change
... whole process, CR, etc.

<dsinger> s/on incorrect/or incorrect/

CMN: 10 week process for 3 hours of actual work
... this is not overly onerous
... your characterization is wrong

MC: Fair enough.
... as Steve says, we will talk about it later
... But generally we should make it easier to fix things that are unambiguously wrong

CMN: While I'm here
... I've seen huge editorial changes which seems unimportant but make a big difference

<SteveZ> +1 for Chaals concerns

CMN: actually REC process is really really easy

Steve: I would like to resolve ISSUE-141 with David's text together with the modification he proposed today.
... Objections?
... consider that resolved.

Resolved: We will resolve ISSUE-141 with David's text together with the modification he proposed today.

<SteveZ> RESOLUTION: resolve ISSUE-141 with David's text together with the modification he proposed today.

Jeff: Will we see a version today?

Chaals: I will aim to get it out tonight. Feasible, but I have some conflicts.

SZ: Jeff, I hope you can supplement the text with these minutes.
... I also would like to see the wide review section updated.

CMN: I think it is just a resolution I missed.

SZ: Actually, 2 resolutions.
... I sent you the text with all the changes.

Issue-152

<trackbot> ISSUE-152 -- Process2014 Regresses Editorial Revision of RECs -- raised

<trackbot> http://www.w3.org/community/w3process/track/issues/152

SZ: Class 1 errata can be made by the team (structural changes) and Class 2 (editorial changes) can be done by WG in Process2005
... Elika noted it was dropped in Process2014 and requested that it be restored.
... Chaals wasn't so sure.
... I'd like to deal with it in 2015.

CMN: I don't recall the discussion
... I believe that it is because editorial changes are not necessarily editorial
... not a good idea to wave them through
... and if they are really editorial, noone cares

SZ: Test case: Due to editing the spec contradicts itself
... You want to fix incorrect one.
... Not changing, just removing inconsistency
... important

CMN: Silently changing the spec without a BIG warning is a terrible idea
... Some people are doing the wrong thing that they read in the spec
... Not telling the public is irresponsible.
... Nonsense to assume that there are people not following the WG.

<dsinger> we should be able to cope with a message to ACs “WG X has changed Rec Y to fix errata and seeks to publish as an edited Rec. OK?” is that really too heavy?

<chaals> s/public through the review process/

Jeff: I see Chaals' concern, but I don't know if it happens in practice.
... we did not have problems between 2005-2014

MC: Jeff says it well.
... no problems for 9 years
... it was just an unintended consequence of text clarification
... I hear Chaals' concern, but the question is - what is the most authoritative source.
... It's the REC
... Yes, people might be using the original (now deprecated) version
... but more likely is that people will look on-line.
... sure we should flag it with changes
... the DOC itself is the authoritative thing

SZ: Three people (including myself) feel it was an unintended change.
... I'll go back and check the history (whether intended or not)
... and resolve based on that.
... If unintended we revert to Process2005 (on this point)
... If intended we document it as such

<scribe> ACTION: on Steve to dredge up history behind Issue-152 [recorded in http://www.w3.org/2015/01/20-w3process-minutes.html#action01]

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/community/w3process/track/users>.

Chaals: While this did not bite us much for 9 years
... it is because people ignored us.
... the authority should be document
... scenario is more serious than you are thinking about
... I believe the change was deliberate
... I recall it was discussed.

SZ: I simply don't know. Let me investigate.

CMN: OK

SZ: This is not the most important thing.

<chaals> [FWIW Steve's test case is a class 3 situation - conformance is unclear since the spec is ambiguous, and this therefore changes conformance]

SZ: set of open issues will be identified prior to Tokyo.
... Chaals, please update 141 and 148 as Jeff would strongly appreciate.

CMN: Noted.

SZ: Thanks.

[adjourned]

<SteveZ> s/ISSUE-152?/s/ISSUE-152?/TOPIC: Issue-152/

<SteveZ> attendees: Mike Champion, Jeff Jaffe, Chaals McCathieNevile, Steve Zilles

<chaals> rrasagent, draft minutes

<SteveZ> s/Josh_Soref/Josh_Sorel/

- DRAFT -

Revising W3C Process Community Group Teleconference

20 Jan 2015

Attendees

Contents

Open Action Items

Issue-141 Errata management

Issue-152

Summary of Action Items

Scribe.perl diagnostic output