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

With one exception, I have addressed all these comments (and the exception  
I expect to address later tonight).

Changes will be in the next draft which will be pushed some time in the  
next few hours.

On Tue, 11 Feb 2014 06:41:15 +0100, Ian Jacobs <ij@w3.org> wrote:

> - Preamble: "Errata cannot be made normative except by republishing a
>   Recommendation or a Revised Recommendation". I think "republishing a
>   Recommendation" is the same as "a Revised Recommendation". If that's
>   not the case, please explain, otherwise you can probably just say
>   "by revising a Recommendation."

Sure - although that content will go away when we publish the full process.

> - 7.1: Suggest changing text from: "For a technical specification,
>   once review suggests the work has been completed and the document is
>   good enough to become a new standard, there will then be a Candidate
>   Recommendation phase..."
>  To: "For a technical specification, once review demonstrates that a
>   group has fulfilled its technical requirements, there will then be a
>   Candidate Recommendation phase..."
>
>   Rationale:
>
>    * "Good enough" sounds informal an ill-defined
>    * The phrase "work has been completed" may be misleading
>  The proposed language is drawn from the language used in the CR
>   maturity level definition.

Used "satisfactorily met the requirements", and edited that a bit more -  
shorter sentences, hopefully better text.

> - Four separate sections of the document talk about Notes: 7.1 (2
>   paragraphs), 7.1.2 (1 paragraph), 7.3.3 (1 paragraph), and 7.8 (a
>   few more paragraphs). I believe you can consolidate all this text
>   and remove some of the redundancy. I am happy to propose concrete
>   edits if you think that would be useful.

This bit remains to do. But I'll have a look at it myself tonight...

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

> - Some places that are missing text following the reintroduction of PR:
>
>   * 7.1.1: In the first list, missing a bullet for PR

Fixed

>   * 7.4: In the first list, missing PR as expected next step.

Fixed

> - 7.1.2: "Substantive changes must not be made to a Proposed
>   Recommendation except by publishing a new Candidate Recommendation."
>
>   Is it possible for the Director to return a PR to WD?

Yep (defined elsewhere). changed to 'WD or CR'. (In principle the group  
might decide on their own to go there.

> - 7.1.2: "Editor's drafts have no official standing whatsoever, and do
>   not imply consensus of a Working Group or Interest Group, nor are
>   their contents endorsed in any way by W3C."
>
>   I suggest "do not necessarily imply consensus of a WG or IG."

Makes sense. Done.

> - 7.2.3.1 Wide review. Suggest changing "A recommended practice is
>   making a specific announcement to other W3C Working Groups as well
>   as the general public, especially the sub-communities thereof that
>   are affected by this specification, that a group proposes to enter
>   Candidate Recommendation in e.g. approximately four weeks. "
>
>   to:
>
>   "Group's SHOULD inform others of their schedule to advance to
>   CR. The recommended practice is to make a specific announcement to
>   other W3C Working Groups as well as the general public, especially
>   to communities with known dependencies."

Seems reasonable given that we try to use the active verb forms of  
RFC2119. This was wording specifically agreed to, so I will raise an issue  
on the off-chance that someone gets upset by the change.

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

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.

>  2) "created by other" suggest "created by other people"

Done.

>   3) "creation, consuming, publishing" are different forms of speech.
>      One alternative: "(authoring, consuming, publishing...)"

I used "authoring".

> - 7.3.2 (editorial): s/from review from beyond/from review beyond/

Done

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

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

fixed

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

> - 7.5: "must identify where errata are tracked, and". I believe that
>   we only start caring about errata a Rec. I suggest deleting this
>   bullet.

Yep, copy paste error. Moved back to Rec.

> - 7.5: "should not approve a Request for publication of a Proposed
>   Recommendation less than 35 days after the publication of the
>   Candidate Recommendation on which is it based [editor's note - this
>   is to allow for the patent policy exclusion period to expire]"
>
>   Please simplify to:
>
>   "should not approve a Request for publication of a Proposed
>   Recommendation sooner than 150 days after the publication of the
>   First Public Working Draft." That's the duration used in the patent
>   policy; it will be easier to explain and remember, instead of
>   introducing a new number "35".

(See ISSUE-86 and the thread that followed from this for the plan)

> - 7.5: For other steps you have a "Possible next steps" section; this is
>   missing for PR.

Fixed.

> - 7.7.1: Errata management. Is this text still relevant given the
>   harmonization of the substantive change language?
>
>   "Note: Before a document becomes a Recommendation, the W3C Process
>   focuses on substantive changes (those related to prior
>   reviews). After a document has been published as Recommendation, the
>   W3C Process focuses on those changes to a technical report that
>   might affect the conformance of content or deployed software."
>
>   Seems like it can be deleted now.

Agree. Done.

> - 7.6 W3C Recommendation
>
>   "The Director must announce the provisional approval of a Request
>   for publication of a W3C Recommendation to the Advisory Committee,"
>
>   I agree the Director must provide rationale for overriding formal
>   objections. The Director can do so in the Director's decision. But
>   we should not add a 14-day waiting period after the close of PR
>   review. There has never been an appeal of a Recommendation
>   decision. So the 14 days will almost never serve any purpose. If
>   there is ever an appeal we can deal with it then.
>
>   Please do not include this requirement to announce provisional
>   approval.

This was a copy/paste error when reintroducing Proposed Rec. The Director  
has to announce publication to the AC (inter alia, the rest being listed  
in a different bullet).

Fixed.

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

cheers

-- 
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:00:51 UTC