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

I have an action item to collect issues and make sure we have them in our  
tracker.

For some of David's comments below I have raised issues. For those I  
believe are truly editorial, I have said what I propose to do - this is  
open to discussion, but I have not raised an issue.

To continue a discussion on a particular issue, please use the thread that  
began with the issue.
Where I propose to do nothing or to make a change that I claim below is  
editorial, if you disagree please raise an issue.

On Tue, 17 Jun 2014 14:42:18 -0400, David Singer <singer@apple.com> wrote:

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

ISSUE-101

I agree that this would be great. Making diagrams is (at least for me) a  
very time-consuming activity, and I don't believe the Process is so  
unclear that it cannot be adopted without better ones (currently we don't  
have any at all, so those in the proposal are IMHO a big improvement).  
Naturally, I accept patches…

>> 4. I would prefer that a formal document like this not have text in a  
>> section before the first sub-section heading.

This is purely editorial. I prefer that text applicable to a section not  
be moved into a subsection, even if that leads to the odd situation of...

Section X
    Something about the topic
  Section X.1
    The only subsection.

It helps to clarify the outline. I propose to "wontfix" this, so unless  
someone raises an issue I plan to forget it.

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

ISSUE-102

I propose instead to note that IPR commitments *only* cover  
Recommendations, in the Maturity levels section.

The only mention of Notes before this points out they have no formal  
standing as a recommendation of W3C, which I think is enough in the  
context.

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

As discussed in the walkthrough, we could either remove the note, or copy  
the normative text from further down. I propose to remove it.

>> 7. 7.2.1. Please clarify "who developed the specification" as being  
>> (typically?) the W3C WG

This is trivially editorial and I believe we can do it without discussion.

>> 8. 7.2.2 They need to document the identity/existence of  
>> implementations, not the implementations themselves.

"known implementation" is an abstract noun and modifying adjective,  
meaning what you mean. However, since the comment has come up before, I'll  
change the phrasing. This is trivial editorial and I don't think needs  
discussion.

>> 10. It may be worth mentioning liaisons as a way to ensure broad  
>> visibility and opportunity to review.

This is editorial, and while it may be worthwhile, I don't think so. There  
are several mentions to identified dependencies, and liaisons are  
typically identified in charters. I don't see the value of the extra  
verbiage.

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

This is editorial. I propose to *remove* the parenthetical aside.

>> 15. 7.3.1 must meet the "applicable" general requirements…

This is editorial but a good clarification. I propose to do it.

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

This is editorial.

W3C style, for ease of translation and comprehension, is to prefer the  
active voice.

>> 21. Rescinded clauses. Please note that the prior version of the  
>> recommendation remains, by policy, available indefinitely also.

This is a corollary of sentence 3, paragraph 1 of 7.2.1

I think being explicit here is a useful editorial clarification and  
propose to do it.

> Minor, perhaps only editorial:
>
>> 2. For each call for a formal review, please be clear what the question  
>> being asked is.

This would be new, but I think it is a useful, editorial suggestion.  
Advisory committee review is formally defined elsewhere in the process,  
but I think we can sensibly clarify in this chapter that the review is to  
determine whether the document is suitable to adopt as a W3C  
recommendation.

>> 13. 7.2.4 Consider mentioning plugfests or other explicit interop events

This is editorial. I considered it and don't propose to do so.

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

This is editorial.

I believe that it is obvious that changing things around a 'MUST' can  
affect conformance - but saying this would in fact focus attention too  
tightly. In practice, changes to other statements can affect conformance,  
and all changes should be considered carefully.

>> 16. 7.3.1 significant changes to "a previous public document, or" when  
>> it would benefit from review…

This is a minor editorial clarification, and I propose to do it.

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

Yes.

The 2005 Process takes a lot of time to define an Edited Recommendation as  
a special state, which doesn't seem worthwhile, and doesn't resolve  
anything - in particular regarding titles, versions, etc - except that  
formally it could be considered different from a Recommendation. It is  
unclear what problem that solved.

I don't propose to address this further, unless someone else raises an  
issue.

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

This was discussed earlier, and we decided at the time that it was a  
sufficiently unlikely case, and sufficiently difficult to find an actual  
problem, that dealing with it formally was just pointless busywork.

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

ISSUE-100

There are use cases for not having the extra delaying step. They are  
generally rare, and the normal practice is to check if an exclusion period  
is open before granting a transition. I'll carry on discussion in a  
separate thread.

>> 12. 7.2.4 Please mention some of the possible counter-indications, e.g.  
>> are there reports of interop. problems

This is editorial (since it occurs in a non-exhaustive list of what the  
director MAY consider), but a useful addition. I propose to add it as is.

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

The things the director MAY consider are non-exhaustive. I think this is a  
useful clarification with practical implications, and propose to add it.

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

Working Group decisions are described in Chapter 3. I don't propose to  
address the question, since the AB has decided that this revision should  
only be of Chapter 7, but feel free to raise an issue - or to request that  
the AB change its earlier decision.

cheers

Chaals

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

Received on Wednesday, 18 June 2014 16:25:56 UTC