Re: The Chapter 7 requirements for issuing a document

On Fri, 19 Jul 2013 21:36:01 -0700, Stephen Zilles <szilles@adobe.com>  
wrote:

> I went thru the listed "requirements" (some are SHOULDs) for advancing  
> documents along the Chapter 7 "REC track". I have attached an Excel  
> spreadsheet which has the various requirements as rows and the various  
> kinds of documents as columns. (Except there is an extra column which is  
> the General Requirements for Advancement on the Recommendation Track.

Thanks for doing this.

> Based on this document I make the following observations.
>
> 1.       I am not at all sure that it is worthwhile having General  
> Requirements for Advancement (section 7.2) There seem to be too many  
> special cases to make it worthwhile. Looking across the table, there  
> seem to be exceptions to every single "General Requirement". If that is  
> that case, then why have them.

Actually, I see no exceptions or changes for
Must record decision to publish, should document editorial changes, must  
document substantive changes (there are *additional* requirements on those  
that come after LCCR but they are not exceptions), must formally address  
comments, must document formal objections.

In addition, it seems to me that "should document known implementation"  
makes sense all the way through the process, so is a candidate to become a  
general requirement.

which would make 6 requirements that carry through (a new one plus 5 of  
the current 7 in my editor's draft, where I dropped two of the should  
requirements in line with issue 37), with the other 2 going from should to  
must at LCCR, and therefore canidates for dropping from the general  
transition requirements.

> 2.       "Heartbeat" Working Drafts are steps along the Process, but  
> have many fewer requirements than the more formal steps (FPWD, LCCR,  
> Request for REC)

Yes. In particular, there is no requirement for a transition. FPWD and  
LCCR have implications for the patent policy. Rec is a big deal for W3C.  
But it makes sense to make it as easy as possible to publish a heartbeat  
draft. I think "living standards" are not useful to an important community  
who is served by heartbeats and recommendations (not just for patent  
policy, but for normal work) but I am sympathetic to the argument that it  
should be easy to publish a heartbeat draft. Indeed, in specs I ahve  
worked on, I've happily published them twice in a month, which is I think  
about as fast a rhythm as is useful (if you want something more frequent  
you should be looking at the editor's draft).

> 3.       I have the feeling that the "General Requirements" were not  
> intended to apply to "Heartbeat" Working Drafts,

No. A Heartbeat is not a new step in the process (see the first sentence  
of the second paragraph describing them).

> but these drafts are steps along the Process. This makes for confusion.
> For example, "Heartbeat" WDs explicitly call out that significant
> editorial changes  SHOULD be identified, but the other steps leave this
> to the General Requirements. Should not all steps work the same way?

No, because they are not the same. (This is precisely the counter-argument  
to the one above in which all steps should define their requirements  
individually since some of them are unique to that step...)

> 4.       Some cells that are empty (because the general requirement is  
> supposed to apply or it is too soon to have to respond) may need to be  
> filled in.  For example, the General Requirements say all comments  
> should be 'formally addressed', but the Request for Recommendation step  
> repeats this requirement. How should this be interpreted?

More carefully. The request for recommendation makes an explicit  
requirement for documentation - until then documenting it is a good  
practice, but there is no formal check and therefore no formal requirement.

> 5.       The handling of "Demonstrating (at least two*) interoperable  
> implementations for each feature" is ill specified and confusing among  
> the steps. * Having two implementations is currently a goal, not a  
> requirement.

Yes. There is an outstanding action item to deal with this.

> 6.       Only LCCR has a fixed (minimum) time for comments. Should not  
> this also apply to Request for Recommendation?

"The Advisory Committee review of the technical report must continue at  
least 28 days after the announcement of provisional approval to publish  
the Edited Recommendation as a W3C Recommendation."

Perhaps reodering this section would be helpful, or adding an informative  
timeline.

> 7.       The statement of "requests for publication" are different,  
> perhaps necessarily, but it is still confusing.

Idon't see where they are different except that "All Recommendations"  
places requirements on the director that are a superset of those for  
making an LCCR into a recommendation. I think reordering the section (as  
suggested above) could remove the redundancy and hence reduce the  
potential for confusion.

> 8.       It would be helpful (IMO) to list the requirements in each step  
> in the same order.

Agreed. I'll find some time to do that, hopefully this week.

cheers

chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Sunday, 21 July 2013 10:32:03 UTC