Re: Ian Jacobs comments [Was: New draft - please review]

On Fri, 14 Feb 2014 22:26:32 +0100, Ian Jacobs <ij@w3.org> wrote:

> On Feb 14, 2014, at 3:00 PM, "Charles McCathie Nevile"

>> Ian, previously suggested...
>>
>>> - 7.1: "Individual Working Groups and Interest Groups may adopt
>>>  additional processes for developing publications, so long as they do
>>>  not conflict with the requirements in this chapter."
>>>
>>>  Proposed editorial change: "Different Working Groups and Interest
>>>  Groups typically evolve different internal processes for developing
>>>  documents. Such processes MUST NOT conflict with the requirements in
>>>  this chapter."
>>>
>>>  I think the word "Additional" does not quite capture what I think
>>>  you are referring to: operational details (which may very by group).
>>
>> Other processes are in addition to the base requirements of the process  
>> which cannot be broken. I had't used MUST because this chapter doesn't  
>> cover charters and working groups - that's a different part of Process  
>> that was ruled out of scope for this round of updates.
>>
>> I therefore oppose this change. Feel free to raise an issue.
>
> I understand your point and agree the requirement should not appear in  
> this section. Counter proposal:
>
>      "Different Working Groups and Interest  Groups typically evolve  
> different internal processes for developing
>      documents; these complement but do not override the requirements in  
> this chapter."

I'm not sure what this achieves that the current text doesn't. I don't  
think it is that typical for groups to evolve additional processes,  
although there are some notable cases.

Still no change made.

>>> - 7.2.4:
>>> 1) "to ensure that independent interoperable implementations of each
>>>  feature of the specification will be realized." Suggest s/will/can/
>>
>> That is a significant change that I oppose. The point is not that it is  
>> possible to make interoperability, but that the specification is  
>> sufficiently clear that this is what *will* happen.
>
> I don't object to "will," but I think "can" reflects the "feasibility"  
> goal better than will here.
>>
>> This is part of the rationale for saying "2 interoperable  
>> implementations" is a rule of thumb that suggests we're on the right  
>> track, not a statement of what the world is actually looking for in a  
>> standard, and therefore providing 7.2.4 instead of that rough rule.

In other words, the goal isn't just feasability. It is achieving this  
effect in practice.

I accept your argument but reject the premise about the goal, and  
therefore the proposed change that flows from it.

Still no change.

>>> - 7.4.1: Suggest deleting this section and simply incorporating
>>>  what's needed in 7.4.
>>
>> I disagree. This section was added because nobody could work out what  
>> was required (because it is unclear).
>
> What I had in mind was to say, for example where it says in next steps  
> "Return to CR" something like:
>
>  "If there are any substantive changes made to a Candidate  
> Recommendation other than to remove features explicitly identified as  
> "at risk", this is the required next state."
>
> And then, looking back at the entrance criteria for 7.4, they all pretty  
> much still apply for a revised CR, so can't we just reuse them as-is?

Not so readily - only a subset of them apply and there is an extra one.

This section was put in place as part of the resolution of ISSUE-59 withan  
explicit request not to simply re-use the rest of the section.

Note that I also erroneously agreed with an earlier comment:

> Also note the missing word "NOT" in "MUST [NOT] approve the publication
> of a revised CR."

What the TF actually agreed (in relation to ISSUE-77 at the 3 Feb meeting)  
was that the WG needed formal approval to publish a CR with any  
substantive change beyond removing things at risk.

This is because the republication with substantive changes probably  
requires an exclusion. In the Patent Policy it is the Team Contact's  
responsibility to do this, but everywhere in the Process we use "director  
approval" to mean something where the WG needs permission from W3C - in  
practice most approvals are delegated.

So I've changed the text in the first para of 7.4.1 to read "...the  
Working Group must obtain the Director's approval to publish..." to  
clarify (the old wording was indeed highly ambiguous).

>>> - 7.4: "The Director must announce the publication of a Candidate
>>>  Recommendation to other W3C groups and to the public, and must begin
>>>  an Advisory Committee Review of the specification on publication."
>>>
>>>  Suggest deleting "on publication" as unnecessary (and possibly
>>>  over-constraining).
>>
>> It is a rational requirement. I don't think it is *over*-constraining  
>> to mention when the review begins, and I don't see a better alternative.
>
> My point is that the beginning of the sentence says "must announce the  
> publication". So now we know there has been a publication. The sentence  
> then adds "and must begin an AC review". So saying "on publication" is  
> unnecessary since you already referred to the
> publication event.

Ah, OK. Change made.

>>> - 7.9 Rescinding a W3C Recommendation
>>>
>>>  I still believe this section is confusing. See my suggested changes
>>>  from December:
>>>  http://lists.w3.org/Archives/Public/public-w3process/2013Dec/0043.html
>>
>> The current approach was resolved by the TF as ISSUE-78  
>> https://www.w3.org/community/w3process/track/issues/78
>>
>> If you think we should make further changes, please reopen that issue.
>
> Noted.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Friday, 14 February 2014 21:50:58 UTC