Re: Comments on https://dvcs.w3.org/hg/AB/raw-file/5508dec95a6a/tr.html

Hi guys

just so we’re clear, here are my comments, categorized. Note what I said in my preamble:

> Most of these requests are editorial or clarification, and a few are more substantive. Of the substantive ones, many if not all relate to pre-existing text. I hope that we can deal with the editorial ones now, and file issues for an update on those we feel unable to do.

Editorial:

> 1. Please provide a diagram showing for each state what the condition of the document is (stable, possibly unimplemented, for CR, for example), and for each transition, what the triggering condition is to take it (not the actions; e.g. WD->CR, WG believes it is ready for implementation)
> 4. I would prefer that a formal document like this not have text in a section before the first sub-section heading.
> 5. WG Notes are mentioned many times, and there should be a note on the first mention that they have no standing under the IPR Policy.
> 6. 7.1.2 The note should be a normative statement "For the purposes of the IPR Policy, a CR as defined here is a LCWD as defined there.”
> 7. 7.2.1. Please clarify "who developed the specification" as being (typically?) the W3C WG
> 8. 7.2.2 They need to document the identity/existence of implementations, not the implementations themselves.
> 10. It may be worth mentioning liaisons as a way to ensure broad visibility and opportunity to review.
> 11. 7.2.4 In the example, it's not the existence of a test suite we care about, it's that implementations pass it.
> 15. 7.3.1 must meet the "applicable" general requirements…
> 18. 7.4.1 please rewrite the phrase on at-risk features, to match the earlier text "for a feature to be formally at-risk, it MUST be documented…"
> 21. Rescinded clauses. Please note that the prior version of the recommendation remains, by policy, available indefinitely also.

Minor, perhaps only editorial:

> 2. For each call for a formal review, please be clear what the question being asked is.
> 13. 7.2.4 Consider mentioning plugfests or other explicit interop events
> 14. 7.2.5 It may be worth saying that particular attention should be given to changes that insert, remove, or change the text around a formal 'must’.
> 16. 7.3.1 significant changes to "a previous public document, or" when it would benefit from review…
> 19. 7.7.2 Do we rely on pubrules to identify how revised recs differ from the previous version (e.g. in title, version, pubdate…)
> 20. 7.8 It's hard to imagine a document getting shelved later in the process, but basically re-entering process is only possible at CR at the latest, isn't it?

Pre-existing condition, not addressed in this revision:

> 3. It is practice, but nowhere written, that a PR transition will not happen while an exclusion opportunity remains open. Please consider documenting that.
> 12. 7.2.4 Please mention some of the possible counter-indications, e.g. are there reports of interop. problems

Maybe significant:

> 9. 7.2.3.1 Please insert the Director will consider "who has been explicitly offered the opportunity and time to review", as otherwise it appears that a refusal to review can block progress.
> 17. The rules for what is a decision are very unclear, and as chairs need to refer to this clause when trying to publish, please clarify. If unanimity isn't required, or consensus, what is?


There are only 2 that worry me.  

The first is addressing a delaying tactic that is in use

The second is a pre-existing condition, but an ongoing problem (see EME and DNT), and chairs would greatly appreciate being able to say that they are following process (and know what it is). Unfortunately, I am not sure what the rule is;  I *think* the answer is that the Chair decides, having taken into account the WG’s advice, i.e. that their agreement, consensus, unanimity, approval, encouragement, indifference, or blood-samples are not needed and not formally part of the process.  (Of course, if the chair is constantly doing things that while in their power are disapproved of by their WG, they may find their chairmanship to be rather short).

On Jun 16, 2014, at 12:57 , Jeff Jaffe <jeff@w3.org> wrote:

> 
> On 6/16/2014 3:50 PM, Wayne Carr wrote:
>> 
>> On 2014-06-16 11:09, Arthur Barstow wrote:
>>> On 6/16/14 1:30 PM, Wayne Carr wrote:
>>>> I assume you are referring to comments that came in as part of the AC review. 
>>> 
>>> Yes.
>>> 
>>>> Those comments appear to me largely editorial and so can be fixed as part of the usual process of considering the AC review and not hold up approval. 
>>> 
>>> Well perhaps so but my understanding is there was agreement this list would be used for tasks such as comment processing. As such, my expectation is the group will review the comments.
>> 
>> I'd think with those comments that anything new that would actually change the process (e.g. wanting some other old text in the process changed that we hadn't been looking at) would likely turn into an issue for this group to look at for the next revision.  But, for something that's clearly an editorial clarification (a sentence could be worded better), I don't think we should keep on iterating through this long process.  i.e. not go back to this list for minor wording review, then do another last call review, then do another long AC review.   That would be months down the road until we're back where we are now.
>> 
>> I like the chapter 7 revisions, very much like that it was done largely in this CG - but this is at a stage where the AC wouldn't be reviewing the comments for editorial changes either -- it would be part of the Director's decision on consensus based on the AC review.  The AC could then appeal the decision if it objected.   I think we should finish this up - and not have it drag on - and start a new round of revisions.
> 
> To clarify the intended process (prior to the Formal Objection).
> 
> If any of the comments were purely editorial, we intended to make changes as part of the Director's Decision.  So we would get the benefits of the comment immediately.
> 
> Since anything substantive would take weeks to agree and then require another Last Call and another AC Review, we had intended to address those as part of next year's revision. As you point out, some of the "historical" issues would be substantive.
> 
> Due to the Formal Objection, the Director needs to determine for which issues (if any) we should do that.  I also called Art to see if I could get clarification whether the Objection applied to all of the Issues (before hopping on a plane), but we have not yet connected.
> 
>> 
>> 
>>> 
>>> -AB

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 17 June 2014 18:42:57 UTC