RE: The Chapter 7 requirements for issuing a document

Charles,
General comment: your explanations below make sense and I agree with most of your assertions. More specific comments are inline below.

-----Original Message-----
From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: Sunday, July 21, 2013 12:31 PM
To: public-w3process@w3.org; Stephen Zilles
Subject: 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.

SZ: I am OK with you six general requirements as long as they are not repeated in the specific sections (especially with slight variations).

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

SZ: Good. I like it being just a step, too. My impression came from General requirements that did not apply and repeats of general requirements that did apply.

> 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...)
SZ: This comment confuses me because the "requirement" referenced is essentially identical (general requirement and heartbeat requirement) and you assert this above in your general requirement paragraph. I am of the opinion that general requirements should apply across all steps without exception.

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

SZ: great

Steve Zilles

Received on Monday, 22 July 2013 05:59:36 UTC