W3C home > Mailing lists > Public > public-w3process@w3.org > March 2014

Re: Draft for Last Call

From: Wayne Carr <wayne.carr@linux.intel.com>
Date: Thu, 20 Mar 2014 11:35:17 -0700
Message-ID: <532B34E5.5070401@linux.intel.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>, public-w3process@w3.org

On 3/19/2014 7:45 AM, Charles McCathie Nevile wrote:
> 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.

I don't think it should be in the process at all - I like the process 
being briefer and easier to read.  I think it's an operational detail.  
But we need some way to signal to people who aren't following the WG 
(don't read its list) that it's time to review something.

>
>> 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".
>
Received on Thursday, 20 March 2014 18:35:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:10 UTC