Re: Draft for Last Call

TL;DR: Agree. Done.
Details inline

On Tue, 18 Mar 2014 00:41:55 +0100, Wayne Carr  
<wayne.carr@linux.intel.com> wrote:

> Suggestions for a few clarifications (not essential - just a few  
> improved wording suggestions).  The chapter looks very good.

Thanks...

> 1. Section 7.1
> "If the Director determines that W3C member review supports a  
> specification becoming a Standard, W3C publishes it as a Recommendation."
>
> Suggest:
> "If the Director determines that W3C member review supports a  
> specification becoming a standard, W3C publishes it as a W3C  
> Recommendation."

Done

> Reason: "Standard" isn't capitalized elsewhere.  Capital "S" Standard  
> isn't defined anywhere.  Also add "W3C" before recommendation because  
> that's how it's referred to immediately above and it reduces confusion  
> by having specification, standard and recommendation in the same  
> sentence - by clearly indicating W3C Recommendation is a special state.
>
> 2. Section 7.2.2
> "Because the requirements for First Public Working Drafts are fairly  
> mechanical, approval is normally fairly automatic. For later stages,  
> especially transition to Candidate or Proposed Recommendation, there is  
> generally a formal review meeting to ensure the requirements have been  
> met before Director's approval is given.  Note that for a First Public  
> Working Draft there is no "previous maturity level"."
>
> Suggest:
> "For a First Public Working Draft there is no "previous maturity level",  
> so many requirements do not apply and approval is normally fairly  
> automatic.  For later stages, especially transition to Candidate or  
> Proposed Recommendation, there is generally a formal review meeting to  
> ensure the requirements have been met before Director's approval is  
> given.

Done as per Ralph's suggested modification.

> Reason: In the current text, it isn't clear why the requirements are  
> "mechanical".  It's because most of them are about documenting things  
> that happened since a previous maturity level so they don't apply.   
> Theproposed  changes combines wording from the two sentences about FPWD  
> and moves them together.  I think that's clearer.
>
> 3. Section 7.2.4 Wide Review
>
> Not suggesting a change to the text - but may want to create a single,  
> public W3C-wide call for reviews mail list to announce requests for  
> reviews.  Otherwise, how does a WG let the general public know it wants  
> a review of some particular section?  There could be  list that only has  
> announcements of calls for review - no ability to respond to that list  
> so people could subscribe and see all W3C requests for draft reviews.   
> Currently, some WGs go to Last Call probably too early to let people  
> know they really want review - should be a list where they can say they  
> really want review (and it is just for requests so the request doesn't  
> get buried in other mail - maybe only chairs can post to it).

This is an operational matter at the moment. At various times we discussed  
raising more of the operation to the level of the process document. I am  
happy with the way it is now, but I think it would be good if there were  
more consistent processes and it was clear where to discover them.

Which would argue in favour of putting it into the process. Maybe when  
we've trimmed the rest of it down some more, rather than in the current  
round of revision which only covers chapter 7.

> 4. Section 7.7.2
> "Editorial changes to a Recommendation require no technical review of  
> the proposed changes. "
>
> Suggest:
> "Editorial changes" should like to section 7.2.5 which defines  
> "editorial changes".
> Same for "substantive changes" in the next paragraph.

I linked them - turned out they didn't have any social network accounts  
anyway :)

> 5. Section 7.8
> "This includes supporting documentation for a specification such as  
> explanations of design principles or use cases and requirements,  
> non-normative guides to good practices, as well as specifications where  
> work has been stopped and there is no longer interest in making them a  
> new standard."
>
> Suggest:
> "This includes supporting documentation for a specification such as  
> explanations of design principles or use cases and requirements,  
> non-normative guides to good practices, as well as specifications where  
> work has been stopped and there is no longer consensus for making them a  
> new standard."

Done

> Reason:
> There may be strong interest from some, but not consensus.  change  
> "interest in" to "consensus for".

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

Received on Wednesday, 19 March 2014 14:46:33 UTC