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

On 2014-06-18 15:25, Charles McCathie Nevile wrote:
> 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.

Just so people reading this don't have to look for it, here's the text 
from the new proposed process document says in the Candidate 
Recommendation section:
"A Candidate Recommendation corresponds to a "Last Call Working Draft" 
as used in theW3C Patent Policy 
<http://www.w3.org/Consortium/Patent-Policy>[PUB33 
<http://www.w3.org/2014/05/Process-20140506/refs.html#ref-patentpolicy>]. Publishing 
a Candidate Recommendation triggers a Call for Exclusions, persection 4 
<http://www.w3.org/Consortium/Patent-Policy/#sec-Exclusion>of theW3C 
Patent Policy <http://www.w3.org/Consortium/Patent-Policy>[PUB33 
<http://www.w3.org/2014/05/Process-20140506/refs.html#ref-patentpolicy>]."

The text that's objected to is it saying in the list of Maturity Levels: 
"*Note:*Candidate Recommendation is the state referred to in theW3C 
Patent Policy <http://www.w3.org/Consortium/Patent-Policy>[PUB33 
<http://www.w3.org/2014/05/Process-20140506/refs.html#ref-patentpolicy>] 
as "Last Call Working Draft""

I think it's useful to have that note in the list of maturity levels.  
Someone looking at that section (who knows about the patent policy) may 
wonder what happened to Last Call.

The note could be:  "*Note:*Candidate Recommendation serves as the "Last 
Call Working Draft" referred to in theW3C Patent Policy 
<http://www.w3.org/Consortium/Patent-Policy>[PUB33 
<http://www.w3.org/2014/05/Process-20140506/refs.html#ref-patentpolicy>].  
Please see Candidate Recommendation 
<http://www.w3.org/2014/05/Process-20140506/tr.html#candidate-rec> below 
for details."

Making the wording more similar without duplicating it all and referring 
to where the longer statement is I think would be better. ("Candidate 
Recommendation is the state" sounds slightly off.  CT is more than 
that.  It's just one of its roles.)

I don't have any objection to deleting the note or leaving it as it is.




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

As noted this one is to address something in the existing process, not a 
change proposed in this round of process revision.  Deferring this one 
until the next round of process revisions is the right approach.

In any case, I don't think it's a change that should be made.  There 
hasn't been an actual instance of this being a problem and we shouldn't 
require the delay in instances where it may be unnecessary.  e.g. the 
most minor conceivable feature addition to a spec that is very unlikely 
to have patent concerns because it involves a very old technology 
already used widely and included by reference (so no essential claims).  
By current rules that would take a minimum of at least 5 months.  This 
proposed addition would make it 6 months.


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

I agree.  This should not hold up approval for the Chapter 7 changes.  
There's a very long section on how WGs make decisions starting at 
http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus

>
> cheers
>
> Chaals
>