Re: Some comments "Rec Track Process"

On Jul 9, 2013, at 8:04 PM, Sandro Hawke <sandro@w3.org> wrote:

> 
>> 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.

+1 more or less. (I proposed WD ---> LCCR ---> REC). 

Here's what I think we do need:

 * To make clear that there are entrance requirements at the first WD.
 * To bind terms to terms in the patent policy

But it can probably be done with a light touch.

[1] https://lists.w3.org/Archives/Team/ab/2013JulSep/0028.html


> 
> - 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.)

I'd like for the diagram to be interactive, so you can click on an arc and find the entrance requirements for the next state. ("Process
document as single diagram. :)

> 
> - 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.)

+1 to not having a rule that constrains the type of content that can appear in a Note.

(There's an extra cost to that, however, which is that you have to explain the group's expectations in the status
section, and I'm told people don't read status sections.)

> 
> - 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.)

Here's what I wrote about errata in [1], with you in mind:

---
 - 7.6.1: Some people have pointed out to me recently that this text
 is problematic: "The Working Group must identify which corrections
 are normative." It becomes even more problematic now that we have
 dropped the alternative path to PER. In short: there will never be
 normative corrections in an errata page. We __could__ say:

  "The Working Group SHOULD identify which corrections, once formally
  incorporated into a revised Recommendation, they believe would have
  an impact on conformance."
----

Would that work for you?

Ian

> 
> 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
> 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                                          +1 718 260 9447

Received on Wednesday, 10 July 2013 02:35:21 UTC