- From: <timeless@gmail.com>
- Date: Tue, 12 Aug 2014 18:37:31 -0400
- To: public-w3process@w3.org
I'm sorry that I didn't send this feedback on [8] earlier, I've been busy.
I sent notes about ProcessTransition2014 [1], Ian has made some changes [2] to it in response.
{Section 7}
> The W3C technical report development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology.
> The W3C technical report development process is designed to
> support multiple specification development methodologies
> maximize consensus about the content of stable technical reports
> ensure high technical and editorial quality
> promote consistency among specifications
> facilitate royalty-free, interoperable implementations of Web Standards, and
> earn endorsement by W3C and the broader community.
Normally bulleted lists are preceded by <:> and in sentence form have trailing <,> / <;> on each line that isn't the last. As the second to last line ends with <, and>, I think the preceding lines should end in <,>
> Please note that publishing as used in this document refers to producing a version which is listed as a W3C Technical Report on its Technical Reports page http://www.w3.org/TR.
A version <of-what> ?
Perhaps a version of a document?
> while the Working Group formally collects implementation
There's a stray space after <collects>
> 7.1.1 Recommendations and Notes
> Publication as a W3C Recommendation.
> Possibly, Publication as an Edited Recommendation
> First WD -> WD* <-> CR* <-> PR -> REC
ER isn't in the graphic
> W3C may end work on a technical report at any time.
Is <technical report> here <TR>? If so, shouldn't it be "Technical Report"? Also, shouldn't there be a "<someone> SHOULD publish a NOTE explaining that work has stopped"?
> Any Working Draft not, or no longer, intended to advance to Recommendation should be published as a Working Group Note.
Note that this is similar to what I'm suggesting, but is too late and too specific, if moved earlier and generalized, you could insert "Once at least one draft is published, it should go through the Note phase if not/no longer intended to advance to Recommendation"
> Proposed Recommendation
Why isn't PR in this line?
> W3C Recommendation (REC)
There should be a note explaining what Maturity level an Edited Recommendation has.., probably just a sentence in REC saying that an ER is considered a REC from the Maturity perspective.
> An editor must be a participant, as a Member representative, Team representative, or Invited Expert in the Group responsible for the document(s) they are editing.
Can two groups work on a recommendation together? If so, does an editor only have to be a member of one?
{to read: 7.3}
> For all Public Working Drafts a Working Group
There's no punctuation at the end of this thought, perhaps ":" or "..." ?
> * should document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
> * may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.
> To publish a revision of a Working draft, a Working Group
There's no punctuation at the end of this thought, perhaps ":" or "..." ?
> must record the group's decision to request publication. Consensus is not required, as this is a procedural step,
> must provide public documentation of substantive changes to the technical report since the previous Working Draft,
> should provide public documentation of significant editorial changes to the technical report since the previous step,
> should report which, if any, of the Working Group's requirements for this document have changed since the previous step,
Generally the second to last item in a list has used <, and>, instead of <,>.
> should report any changes in dependencies with other groups,
This last one ends with a <,>, perhaps it should end with a period?
> Possible next steps for any Working Draft:
> Revised Public Working Draft
> Candidate recommendation.
This middle item has a <.> which is odd.
> Working Group Note
[3]
> Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further.
The <it> in that sentence is problematic
It's ambiguous
it=w3c? it=wg ?
> If the Director closes a Working Group W3C must publish any unfinished specifications on the Recommendation track as Working Group Notes. If a Working group decides, or the Director requires, the Working Group to discontinue work on a technical report before completion, the Working Group should publish the document as a Working Group Note.
If the WG closes on its own, <SHOULD> the W3C publish Notes as if the Director had closed the group?
> may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.
s/a requirement/triggering a requirement/
> and must begin an Advisory Committee Review on the question of whether W3C should publish the specification as a W3C Recommendation.
Please linkify <Advisory Committee Review>
> A Candidate Recommendation corresponds to a "Last Call Working Draft" as used in the W3C Patent Policy [PUB33].
Is there an issue raised against the Patent Policy for an #anchor for LCWD?
> If there was any dissent to the Working Group decision to request advancement Advisory Committee representatives may appeal the decision to advance the technical report.
Insert <,> after <advancement>.
> "at risk"
This is used in a bunch of places, could it please have an anchor and a heading in the ToC?
> If there are any substantive changes made to a Candidate Recommendation other than to remove features explicitly identified as "at risk", the Working Group must obtain the Director's approval to publish a revision of a Candidate Recommendation
The second <a Candidate Recommendation> should be <the Candidate Recommendation> to refer to the precise CR from the beginning of the sentence and not just some other random CR.
> must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
Some sentences like this one are probably the same as in other sections, it'd be nice if there was an indication that a sentence is the same as in other sections, or is different from other sections -- instead of making the reader figure it out (and risk getting it wrong).
> The Director must announce the publication of a Candidate Recommendation to other W3C groups and to the public,
> The Director must announce the publication of a revised Candidate Recommendation to other W3C groups and the Public.
The language here diverges at the end: <the public> vs. <the Public>. Please be consistent.
> Advisory Committee review now begins at the same time as Candidate recommendation, but still ends no less than 4 weeks after publication as a Proposed Recommendation.
> The status information must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per section 4 of the W3C Patent Policy [PUB33].
Some sections use 4 weeks, others 28 days...
> must show that the document has received wide review,
The <,> is included in the link, it isn't in the next bullet:
> must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
> must identify any substantive issues raised since the close of the Candidate Recommendation review period by parties other than Advisory Committee representatives acting in their formal AC representative role,
As this is the second to last item, it is missing <and> before:
> may have removed features identified in the Candidate Recommendation document as "at risk" without republishing the specification as a Candidate Recommendation.
> Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on,
s/from/relative to/ s/it is based on/on which it is based/
> to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.
-> The Working Group must return the specification to Candidate Recommendation or Working Draft to make any substantive change to a Proposed Recommendation.
> A Recommendation must identify where errata are tracked, and
The <, and> here is odd, as this is the first of 4 bullets
> A Recommendation must not include any substantive changes from the Proposed Recommendation on which it is based.
... shouldn't <.> be <,>?
> If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the general public, and must formally address the comment at least 14 days before publication as a W3C Recommendation.
> In this case the Advisory Committee may appeal the decision,
The <,> here is odd, since this blob isn't really using <,> list style, and if it were, it should be the place for <, and> as the second to last item.
> The Director must announce the publication of a W3C Recommendation to Advisory Committee, other W3C groups and to the public.
> A W3C Recommendation normally retains its status indefinitely. However it
<...> or <:>
> from mere editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g., content validity).
I think that you can omit the first <the> here.
> Each Recommendation links to an errata page; see the Team's Publication Rules.
Is there a reason not to include the rfc must (s/links/must link/) ?
Personally "will link" reads better than "links" (although I'd prefer RFC language).
> A correction becomes part of the Recommendation by the process for Revising a Recommendation described in the next section.
A link for <Revising a Recommendation> would be appreciated. I know that it's currently the next section, but it's helpful for those of us who read by link-navigation instead of dead-trees (especially if we use back-forward navigation).
> A Working Group should keep their errata pages up-to-date, as errors are reported by readers and implementers. A Working Group must report errata page changes to interested parties, notably when corrections are proposed or incorporated into an Edited Recommendation, according to the Team's requirements.
When a WG dies and some of their RECs have not yet been rescinded, who is responsible for the errata page?
> A Working group may request republication of a Recommendation, or W3C may republish a Recommendation, to make corrections that do not result in any changes to the text of the specification.
I'd s/changes/change/
> Editorial changes to a Recommendation require no technical review of the proposed changes.
As written, I'd drop <of the proposed changes>, it's circular, but instead:
-> The Editor/WG can accept proposed <Editorial changes> to a Recommendation without technical review.
or
-> The WG is not required to do a technical review for <Editorial changes> to a Recommendation.
Both of these are more precise than the current version as they indicate who the actor would be. If it could be "W3C" instead of Editor/WG, then it should be spelled out. If it can't be WG, the text should specify W3C (or whatever party can make the changes).
> A Working Group may request publication of a Proposed Recommendation or
There's a double space before <or>
> W3C may publish a Proposed Recommendation to make this class of change without passing through earlier maturity levels.
> Such publications are may be called a Proposed Edited Recommendation.
<are may> isn't grammatically valid.
(omit are)
> When requesting the publication of an edited Recommendation as described in this section, in addition to meeting the requirements for the relevant maturity level, a Working Group
<...> or <:>
> For changes which introduces a new feature or features, W3C must follow the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.
Why does this say <W3C>? Should it say "the WG and W3C" or "the WG/W3C"?
> This includes supporting documentation for a specification such as explanations of design principles or use cases and requirements,
s/ or /, /
> 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.
> may publish a Note with or without its prior publication as a Working Draft.
Why does this end in <.> instead of <,>?
> must record the group's decision to request publication as a Note, and
> should publish documentation of significant changes to the technical report since any previous publication.
> W3C may rescind a Recommendation, for example if the Recommendation contains many errors that conflict with a later version
Can the W3C rescind if W3C publishes a competing Rec that obsoletes it? Instead of a later version of the same name? (Roughly, if the spirit of the document grows a new monicker, but it doesn't have the same name and is thus not "a later version")
> W3C only rescinds entire specifications. To rescind some part of a Recommendation, W3C follows the process for modifying a Recommendation.
Is there a reason not to use RFC language here?
> To propose rescinding a W3C Recommendation, a Working Group or the Director
<...> or <:>
> must publish rationale for rescinding the Recommendation.
> should document known implementation.
Is there a reason to include <.>s here? The next sections generally don't
> In addition a Working Group requesting to rescind a Recommendation
<...> or <:>
> must show that the request to rescind has received wide review
(no <.>)
> In addition the Director, if proposing to rescind a Recommendation
<...> or <:>
> must show that the request to rescind is based on public comment
(no <.>)
> The Director must announce the proposal to rescind a W3C Recommendation to other W3C groups, the public, and the Advisory Committee.
Is there a reason to list <the public> before <the AC>? Normally I believe that <the public> is last.
> The announcement must:
> indicate that this is a Proposal to Rescind a Recommendation
Is there a reason not to end with <,>?
> specify the deadline for review comments, which must be at least four weeks after announcing the proposal to rescind.
Is there a reason to end with <.> (instead of <,>)?
> identify known dependencies and solicit review from all dependent Working Groups;
Is there a reason to end with <;> (instead of <, and>)?
> If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the public,
> and must formally address the comment at least 14 days before publication as a Rescinded Recommendation.
s/the/each such/
s/as a/the/ (see earlier about articles)
> A Rescinded Recommendation must be published with up to date status.
<up to date status> should be a link to something.
[1] https://www.w3.org/wiki/ProcessTransition2014
[2] https://www.w3.org/wiki/index.php?title=ProcessTransition2014&diff=75757&oldid=75351
[3] http://www.w3.org/2014/Process-20140801/#tr-end
[4] https://www.w3.org/Member/promotion#logos
[5] http://www.w3.org/2009/12/Member-Agreement#also-consortium
[6] http://www.w3.org/2009/12/Member-Agreement#arbitration
[7] http://www.w3.org/2009/12/Member-Agreement
[8] http://www.w3.org/2014/Process-20140801/
Received on Tuesday, 12 August 2014 22:38:01 UTC