Some comments "Rec Track Process"

> Our goal is to have a draft that we can send to Last Call by 
> mid-September. It is, therefore, imperative that you review the 
> changes as soon as possible and provides comments, preferably before 9 
> August so that the AB has time to consider them and respond accordingly.
>
> [2] https://dvcs.w3.org/hg/AB/raw-file/default/tr.html
>
>

This isn't a thorough review, but a few comments.   I'm sorry I haven't 
been able to engage with the CG yet; if these should be raised as 
issues, instead, just let me know.

I'm looking at the "July 9" version: 
https://dvcs.w3.org/hg/AB/raw-file/d97b11a76ac4/tr.html

- FPWD.   I think the distinction between FPWD and HBWD is overplayed.  
Perhaps this is a pet peeve, but whenever I mention FPWD to people 
unfamiliar with W3C process they are confused.  Yes, it's the "first" 
Working Draft, but ... who cares?  Maybe the chairs and the domain lead 
and a patent policy folks care, but that's about it.    Please don't 
give it a special name.

- Consider naming and documenting the arcs in the transition diagram, 
putting more focus on them instead of the nodes.  The really interesting 
part is how we get from nothing to WD, or from LCCR back to WD, etc.   
It matters which arrow you take to get into a state, so document the 
arrows.  At least give them numbers for explanation, maybe give them 
names.  (The old PD did some of this, with "Call for Implementations" 
being the sort of the transition to CR.  Of course it's complicated 
because when you look closely, there are many more smaller states and 
many elements to a transition which we don't quite want to get in to here.)

- The names HBWD and LCCR are fine placeholders, but I don't think 
they're suitable long term.   Some ideas for HBWD: "Working Group 
Draft", "Group Draft", "Consensus Draft", "Public Review Draft", ...  
And for LCCR: "Beta Recommendation", "Preview Recommendation", 
"Implementor's Draft", ....   (Pet peeve: having a second or third 
"last" call.)  Maybe we can focus on what we hope to get from publishing 
documents: call them "Review Draft" and "Implementation Draft".  
(Instead of saying a group is "in CR" we might say it's "waiting for 
implementations".)

- I've seen several groups chartered to write specifications in NOTEs, 
when those specs are side-products, related to the group's main work, 
but not ready for a REC.   So the characterization of NOTEs in this 
draft (as being only for non-specs and RECs that ran out of time) 
doesn't seem right.    (Arguably, we shouldn't charter groups like that, 
but no one objected at the time.)

- Obviously the text about Errata here isn't done.   I suggest we 
rethink this a bit more carefully.  My suggestion would be get rid of 
the term entirely and just think about them as ISSUES raised (by anyone) 
against a REC.  In general, these issues should quickly get to a state 
we might call "Community Consensus", where all the people still 
participating agree about how it should be handled.   Note that there is 
often no WG, and sometimes no staff with any relevant expertise.  We 
could try to make sure there is at least a CG, maybe.   Anyway, when 
there is a WG, those issues on which there is Community Consensus can be 
approved by the AC as part of publishing a new Edition.  Or maybe we 
could do that without a WG??   That'd be nice.  (Speaking of which, 
Edited Recs should be in the state diagram -- Rec pointing back to LCCR, 
I guess?)

(Many people don't realize how the W3C Errata process works.  The text 
in every single Recommendation says that the errata page "may include 
some normative corrections", but that's painfully misleading.  By the 
current process, to make a correction become "normative" requires an AC 
vote.  Ian tells me this has never happened, and that makes perfect 
sense, because if you're going to go to all the work of an AC vote, you 
might as well just do another Edition.   So we tell people in every rec 
that this other page may include some "normative" corrections, but it 
*never* does.  Ouch. Also, it seems to me that's an abuse of the word 
"normative". Something is normative if it tells you what every 
implementation SHOULD or MUST do to be conformant.   Anyone can publish 
a normative correction to a W3C Rec; it just doesn't have any force 
unless it's gone through the W3C process.   So what's really meant here 
is an "official" or "approved" correction.)

I still wish we'd go for a more radical change, separating documents 
from technologies and separating specifications from metadata about the 
specifications and the associated technologies.   I think we could come 
up with a much better collaborative editing, development, and consensus 
system, given the Web we're now building on.   But perhaps that's too 
radical for now.   And the basic concepts of "review draft", 
"implementation draft", and "recommendation" are good and would still be 
needed, so I guess there's little harm in going ahead with this.

        -- Sandro