RE: Proc Doc: time to Slash and Burn, Divide and Conquer, or what?

my comments on the document:

General comments:

* Is it possible to have a copy where the deletions are evident?

* Scope of "consensus"
   In W3C, working groups tend to act as if they have final authority on a spec, and "consensus" is judged by the objections of the members. HTML has gone further and established the "no objections" rule. I think this is a bad rule in general, because the goal of "consensus" is to enable review by the actual community that uses the spec, whether or not they are members of the working group, objections from outside the working group should be noted.  Further, the response to a comment should itself be reviewed by the working group and not just the editor. 

* Goals of tech report development
I think you need to be more explicit about the goals of the tech report development process, and to balance the "maximize consensus about the content of a technical report" (which I don't think is an a priori goal, by which I mean: it should be possible to talk someone into implementing a feature differently than they are holding out for -- avoid being stonewalled.)  I think "broad applicability" is also a design goal. And the process should be explicit about review for cross-working group qualities like accessibility, performance, security, internationalization, etc.  

* Editors
The editors are appointed by group chairs? Without any approval? Or agreement of the committee? "It is the responsibility of these editors to ensure that the decisions of the group are correctly reflected in subsequent drafts ..."
I think it's the responsibility of the chairs to make sure the editors do that? Again, HTML-WG process, the editor proposes the editor's solution to reported "bugs", long before they are "decisions of the group".

"Working Drafts do not necessarily represent a consensus of the Working Group, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology."  At least in HTML-WG, a working draft does not represent consensus to "work on a general area of technology".  In the chartering process, the scope of the working group in the charter, and the initial drafts in the charter, should reflect the agreement to work in an area, and if editor's drafts or working drafts contain technology not mentioned in the charter, this should at least be noted.

* "Non-normative 'Good Practices' documents"    Good practices documents SHOULD be normative and SHOULD be Rec track. Unless they represent consensus of the community, they're not "good practices".

* "A Working Group MAY also publish a specification as a Note ... "  Again, I think it's W3C that publishes everything, and that all NOTEs should have some review from outside the working group.

"7.2 General Requirements for Advancement ..."    I think it's fine to have a MUST even if the MUST is a matter of judgment and can't be automatically determined. It's fine, and appropriate, that a new edition or version MUST provide public documentation of significant editorial changes, changes to working group requirements, show evidence of wide review.

"Wide review": Yes, please define for each level. In particular, a specification should have a _Scope_ section which describes "What is this specification good for" at least in some general terms, and "wide review" should include "careful technical review by the developers of the various roles. (For example, if HTML is good for "rich text email", if that's in scope, then the technical specification for HTML should have careful feedback from the email implementing community.


"7.3 ... existing implementations."  This is the first mention of it. The failure case happens when someone implements a proposed feature and the working group changes it. I think until there's been a consensus call on the feature, "existing implementations" should be discounted.  

"Worthy ideas SHOULD be recorded"  -- this sentence is out of the blue and doesn't really belong. Where should worthy ideas be recorded? Why? What makes an idea "worthy" ?

Heartbeats:
 I think the whole use of heartbeat documents in W3C is broken. A document should only be re-issued if it has changes. The requirement for 'heartbeat' documents should go away. Working groups that update _NO_ documents are dead, there is no heart beat. Otherwise, yes, if you're making editor drafts regularly, you should quarterly converge on a Working Draft, but don't force it.   And yes, documents that are more than a year old without updates should be expired or released as notes or just EDITED to fix SOMETHING.

"must record the group's decision to request advancement. Consensus is not required, as this is a procedural step."  A group without consensus is not a group that has made a decision. Perhaps it's the chairs who request advancement."

"may request publication of a Working Draft even if it is unstable and does not meet all Working group requirements"  I think the problem we've had with heartbeat documents is they can contain technology for which there is no clear agreement that the group will work on the technology, and there's an assumption that working drafts are in Scope.

Finally: There are good recommendations for working group specifications from the QA work many years ago, which I think are worthy of citing and making following (they're full of SHOULDs), including
http://www.w3.org/TR/qaframe-spec/

Received on Wednesday, 5 June 2013 00:58:54 UTC