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

On Feb 14, 2014, at 6:16 PM, Stephen Zilles <szilles@adobe.com> wrote:

> Ian,
> The text proposed  for 7.1 implements the text that closed a prior issue (83) and the changes you suggest would reopen that issue w/o adding anything.

I believe the intent of the text is to say something like "For details about how this gets done in practice, see the charter." But when I read "additional" I don't hear "details" I hear "stuff that is at the same level as what is in this document." I'm trying to convey "details can be found elsewhere."

> My reading of 7.2.4 is a requirement not "feasibility".

I continue to believe the limit of our endeavor is enabling, not producing actual implementations.

Ian

> 
> Fir 7.4.1 I had suggested a different set of changes in an earlier message; e.g., use "Revising a CR" rather than "Revised CR" to avoid the apparent creation of a new state.
> Steve Z
> 
> Sent from my Motorola ATRIX™ 4G on AT&T
> 
> 
> -----Original message-----
> From: Ian Jacobs <ij@w3.org>
> To: Charles McCathie Nevile <chaals@yandex-team.ru>
> Cc: "public-w3process@w3.org" <public-w3process@w3.org>
> Sent: Fri, Feb 14, 2014 21:27:20 GMT+00:00
> Subject: Re: Ian Jacobs comments [Was: New draft - please review]
> 
> 
> On Feb 14, 2014, at 3:00 PM, "Charles McCathie Nevile" <chaals@yandex-team.ru> wrote:
> 
> > With one exception, I have addressed all these comments (and the exception I expect to address later tonight).
> 
> Thanks, Charles. Notes inline.
> 
> Ian
> 
> > 
> >> - 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."
> 
>     (or, "these augment but do not override")
> 
> 
> >> - 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.
> 
> 
> >> - 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?
> 
> >> - 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.
> 
> >> - 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.
> 
> 
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
> 
> 
> 
> 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447

Received on Saturday, 15 February 2014 00:25:43 UTC