- From: Wayne Carr <wayne.carr@linux.intel.com>
- Date: Thu, 20 Mar 2014 11:35:17 -0700
- 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