Chapter 7 Revision

<koaliie> Process chapter 7 draft... [chaals, 3-Mar]

SteveZ: Chaals has been extremely busy, responding to a set of comments
... we reached a document that the TF would like to forward to the AC as a second Last Call
... the target would be to have a document approved by the AC Meeting in June

SteveZ: Ralph sent comments, I send editorial comments too
... we reached a point where comments are largely editorial
... Let's see if we can get a resolution to send this as a final Last Call to the AC within a week or so
... chaals do you want to give an overview of what happened since our last meeting?

chaals: We have reinstated a phase called Proposed Recommendation to clarify the transition process from CR to Rec.
... I'm assuming people have looked at the document, or don't care
... if you don't care, please, don't send editorial comments next week :)
... We talked about reinstating PR at the last teleconference
... I don't thing we've made substantive changes other than that.
... Modulo editorial tweaks, the draft is stable.

SteveZ: Are there issues that people would like to bring up for discussion?

Chris: I had a question about CR
... CR signals the AC should review, but not until PR is a deadline set?
... What's the goal?

chaals: The WG should have but may not have collected implementations experience
... If they haven't done before, they're stuck in CR until they're done
... That's why there is no fixed timeline

chris: Director has to approve the transition anyway, but @@@

Jeff: Once you get to PR you can no longer drop any features

chris: I have no problem with that process; it might be good to tweak it to say clearly what the goals are
... I had to read between the lines to understand the aspect of implementation experience

steveZ: And the IPR review
... you need to complete that

Ann: I liked Chris' point about wanting explanation about each step, and why one moves to the next step. So one doesn't have to 'read between the lines'.
... I read it again yesterday and mostly have grammatical suggestions

Chris: There were reasons for streamlining this and the clearer this is stated, the better.

chaals: We could cross-reference the stages

Chris: The part I got stuck on was what made a spec from CR to PR, how long that was supposed to take
... Even moving between the maturity levels wasn't obvious

chaals: My suggestion would be: Adding a note about getting implementation experience to the maturity levels about PR

<chaals> ACTION: chaals to Add a note about getting implementation experience to the maturity levels about PR [recorded in http://www.w3.org/2014/03/04-ab-minutes.html#action01]

<trackbot> Created ACTION-55 - Add a note about getting implementation experience to the maturity levels about pr [on Charles McCathie Nevile - due 2014-03-11].

Chris: re: claims of independent implementations, I don't know if this needs to be captured better, because a spec is a spec, and not somebody's code.

chaals: There is a tension and I agree with the issue
... The current draft says the group needs to convince the director that it will get independent implementations.

Chris: It's hard to make it a hard requirement.

[Chris gives experience from Audio spec development]

chaals: We did move to try to address it as far as I could figure out how
... I didn't find any way to make a hard requirement that would be useful
... The key phrase is "The Director will consider"

chris: "Independent" vs "independently developed" are different

steveZ: One way out would be to define the intent of "independent" (writing from the specification, or something like that) to clarify the sense
... in a number of groups, this has been interpreted as "not using the same code base"

chaals: My aim is to keep the process reasonably simple and limit the number of clarifications
... because more text also makes the document harder to read.

Mike: Both Chris' comments to me mean that we did a little more work before we take this to the AC
... What we need is not a sentence or two, but a paragraph that gives the philosophy
... of what we are trying to achieve
... We can't specify everything in great detail
... and the Director is going to make a judgement

chaals: There is a paragraph already

Mike: I'm worried we might have this conversation again and again with the AC
... If we give the big picture of the process goal, the role of the Director, etc.

SteveH: in WSI we ran into the same thing
... independent interoperable etc. We left it to the Board to vote
... some people would interpret the whole open source issue

<inserted> Ralph: and judging whether it was necessary to look at the [open] sources to interpret the spec

chris: That's exactly my concern. And I wonder if we are capturing this well enough. I'm hearing this is captured.

SteveH: We left it with these words and left it to those who decide to make a decision
... We voted and in this case the Director makes a decision
... People complain if this is a piece of the same code
... And people should complain if this is the case.

SteveZ: Either we leaves things are is (as chaals said and SteveH said mentioning WSI) or we write about the intent and clarify
... My preference would be the latter

Mike: Every body is sharing source code, this is the reality. What is exactly the role of the Director? I can't find a general overview of what he's trying to ensure.

chaals: There's a section specifically on what the Director is trying to ensure (7.2.4). I'd be concerned with over-constraining

[strawpoll]

SteveZ: 4 for as is

Ralph: I suggest we give more weight to the thoughts those who were in the TF

<tantek> how about asking for objections?

SteveZ: Anything more needed in 7.2.4?

Mike: Earlier than 7.2.4

Jeff: We started with a list of major changes. The philosophy of what we are trying to do is lacking.
... I'd suggest an additional paragraph

chaals: The vision of the process revision is an artifact that doesn't make a difference to the people who are going to follow it.

Jim: There is ambiguity as Chris pointed out.
... if in 7.2.4 we said "how independent are the specifications [...]" would that help?

SteveZ: The other part of the strawpoll: are there people who feel we need to do more?
... 2

Jeff: In 7.2.4

Mike: 7.2.4 is generally OK
... but I like Jim's suggestion
... I know you want to declare victory, but I think we're going to have this all over in the AC.

Chris: We just need concrete suggestions

SteveZ: Adding one more bullet point about "how independent are the implementations"

Jeff: It's likely to create more confusion

Jim: In the 3rd bullet, change to ask how independent the implementations are.

Mike: In the real world implementors will copy the code in polyfills even before the work is brought to W3C

Jim: "How independent are the interoperable implementations" ?

chris: My concern is in making "independent" a spectrum

<AnnB_> suggestion: "Are the implementations adequately independent?"

Chris: "How independent are they and how independently were they developed" ?

SteveZ: the TF chair would like to take Chris' suggestion to modify 2nd bullet
... I believe there is consensus

<cwilso_> are there independent interoperable implementations of the current specification, and were they developed independently from each other?

RESOLUTION: Update the 2nd bullet with "are there independent interoperable implementations of the current specification, and were they developed independently from each other?"

Jeff: I was trying to find the whole question of how and where and when we're going to introduce the process. Is that in this chapter?

SteveZ: No, and it should not be

Jeff: When we ask for the AC approval, we need a cover letter

<scribe> ACTION: SteveZ to include the resolution of issue-39 in the cover letter [recorded in http://www.w3.org/2014/03/04-ab-minutes.html#action02]

<trackbot> Created ACTION-56 - Include the resolution of issue-39 in the cover letter [on Steve Zilles - due 2014-03-11].

Jim: The vast majority of the AC may not read it. Will you be sent to CR stage?

chaals: I presume the Director reads the AC comments. early AC feedback is likely to come up from AC reps who care (whether about getting it done or stopping it). And the start of Patent review should signal time to look at it for interested parties.

Mike: The TF overruled the issue I'm going to bring up.
... We need to say a bit more in 7.1 about what happened to last call and to address the concerns of people for supergroups.
... My suggestion is to put an additional sentence or two at the end to say that those who find LC valuable can put it in their WG charter that they will use it in their process even though the process doesn't require it.
... The other suggestion: In order to help at the beginning of the document, state the goals, acknowledge that more mechanisms may be needed.

SteveZ: The end of 7.1 says that already

Mike: We know what that means. Does the AC know that that means?

SteveZ: The definition of wide review says that LC isn't necessarily sufficient.

Mike: Fair enough, I wanted to see if the whole AB wanted to raise this as an issue.

SteveZ: Does anyone (beside Mike) feel we need to add something to the document?

[none]

chaals: My goal is to say this is good enough, it will work, give it to the AC
... The longer we take to give it, the less agile we are.
... there is diminishing returns on tweaking the text; this is why I asked for concrete suggestions

<Zakim> SteveZ, you wanted to say, do we have a PER

SteveZ: In my review, I noted that in the Edited Rec section there was still a reference to Rec that we dropped
... It wasn't clear to me whether there was exclusion opportunity
... I was a little bit concerned about referring to terminology that we dropped above

chaals: It may be a Copy and paste mistake
... the fundamental question is whether you have to publish a proposed rec or you ask the Director to publish a Rec
... 7.7.2 should point that the process of publishing an edited Rec means you go through Proposed (edited) Rec...

Jeff: and change the bullet(s) underneath

Ralph: Be careful about the fist bullet underneath
... This is the Director who publishes, not the WG.

chaals: Yes Ralph, I agree.

Ralph: Something just came up in an internal conversation
... the question is when we're rescinding a W3C Rec

<Ralph> Rescinding a Recommendation

Ralph: Text in the current process says that there is a publication of a rescinded Red announced that encourages the Team to update the status of the thing that was rescinded
... to note this is no longer a Rec
... in my reading, there is no language in the current proposal to suggest the Team should update a W3C Rec is rescinded

chaals: I agree, and there should be; obvious oversight.

Ralph: The current process doesn't suggest how it should be done, just that it should be done
... The current proposal doesn't even have a suggestion

SteveZ: Accepted

chaals: WFM

Ralph: I'll provide specific language, if you wish.
... Do you need to see specific language? [no]

Jeff: Let's assume that HTML5 points to Dom4 and years later we rescind Dom4

Ralph: Awkward state for W3C to have normative references and we should fix this, but adding language to the process is not necessary

<Zakim> Ralph, you wanted to reply to Jeff

<Ralph> Jeff: perhaps language that suggests that Working Groups who are responsible for such Recommendations review them

Jim: I agree with Jeff

SteveZ: Proposal is to add a bullet to 7.9

Jeff: Or add a new paragraph

SteveZ: the proposal would be to add "WGs or organizations should review their specifications"

chaals: I object to the words and the intent of the proposal
... There's no way that we can be sure that real action is taken, as Ralph said.
... Groups are developing specs under the patent policy, under their charters, etc.
... if they're not solving a problem, the Process isn't going to be able to solve it either.

[Jeff gives an example]

Jeff: What happens to normative references if the process doesn't say a thing about changing but only about the future?

chaals: you can update with a new recommendation, but a stable rec can't be changed; it's part of the guarantee of stability

Jeff: True.
... That's the reason why I proposed mild language.

Jim: In the case where a group has disappeared, what is the right thing, who has the responsibility for the actions?

Jeff: W3C has
... in deciding what to do about it, W3C would have to determine how bad and awful the normative references are
... and W3C might do nothing if the group has disappeared
... or convene a new group to fix the situation

Mike: I'm tempted to agree with chaals. On the other hand, if we find spec bugs, we'd have to go back and fix normative references, maybe in that world we want to provision it in the process

chaals: on the one hand, legacy is big. On the other, who cares? What's the practical impact?
... It's a good idea to clean up
... But as Mike said, solving the purity problem is possibly not worth the effort.

Jim: If the world were the way you describe, I understand. But as Jeff said in his example, there are implications.

chaals: that's why we ask for wide review

SteveZ: summarizing:
... two views
... Wide review will naturally trigger the right thing
... the other view: It's worth putting a sentence.
... Strawpoll

Steve: Raise your hand (4) if we should add that "WGs or orgs should review their specs"

SteveZ: "Organizations which reference this specification should determine whether any action is necessary on their part."

RESOLUTION: Section 7.9, paragraph 3, add "Organizations which reference this specification should determine whether any action is necessary on their part."

SteveZ: We're ready to forward this document as a second last call to the AC, with the idea of immediately following this with an AC review to adopt the document.
... with a cover letter that outlines what we're trying to do with the Chapter 7, and mention issue-39.

Jeff: It seems sensible to me that when chaals has finished his revision he can send it to the AB and give us a week.

SteveZ: I agree, this was my other alternative

Jim: I'd happily rely on chaals
... I have a question on the cover that goes with it
... What about comments outside of chapter 7?
... Are we soliciting comments on the whole document?

SteveZ: The reason for sending the whole document is for people who are concerned that the Chapter 7 doesn't match the whole document

Jeff: We're going only to focus on comments on Chapter 7.

<scribe> ACTION: SteveZ to emphasize that the cover letter should mention comments on Chapter 7 are sought. [recorded in http://www.w3.org/2014/03/04-ab-minutes.html#action03]

<trackbot> Created ACTION-57 - Emphasize that the cover letter should mention comments on chapter 7 are sought. [on Steve Zilles - due 2014-03-11].

SteveH: We need to give the materials to the AC. We're in early March already.

SteveZ: 2 steps left: last call and review. That will take 2 months.
... The ideal is for the review to end after the June AC meeting so the people can discuss it productively at the AC meeting
... but that it be opened before the AC meeting

Jeff: I'm not sure I agree that the review should last 2 months.

SteveZ: Last call is 4 weeks and an AC review is another 4 weeks.

Jeff: OK.
... The last time we did not send the full document

SteveZ: What the AC will review will be a full document as this is what is put forward for adoption
... And for the sake of cohesion with the rest of the process, we're going to send a full document.

RESOLUTION: Chaals will make the edits based on the discussions and submissions of comments to date, we'll have a seven-day review period by the AB, and then a four-week LC to the AC of the full document.

[unanimous support]

<AnnB_> and lots of kudos to those who worked on this, but especially Chaals!