Re: Feedback from Liam Quin - Fwd: Re: Staff contacts review of draft Chapter 7 revision

Further followup. Apart from following up raised issues, I don't propose  
further changes to address the set of comments beyond those mentioned here  
and incorporated in the draft I expect to publish shortly.

If anyone believes further changes are required, please say so.

On Tue, 22 Apr 2014 21:40:31 +0200, Charles McCathie Nevile  
<chaals@yandex-team.ru> wrote:

> On Wed, 19 Mar 2014 23:48:11 +0100, Coralie Mercier <coralie@w3.org>  
> wrote:
>
>> ------- Forwarded message -------

> For really editorial comments, I will just make changes and produce a  
> new draft, I hope tomorrow.
>
>> Note, I read the document once from start to end and made notes as I
>> went - some of the notes might have been changed if I read the document
>> first and then made notes on re-reading, but maybe it's actually more
>> useful like this.

On reflection, not really. Especially as I got this when the document had  
changed again, and in a number of cases the comment seems to have been  
invalidated by changes but without a clearer reference to the section it  
is hard to be sure.

Not that except for lists of purely editorial changes I find it far easier  
to deal with each change in a separate thread. (For substantive issues  
here, a thread will be created by raising an issue in Tracker).

>> 1. (intro) "There is a requirement that Working groups should document
>> known implementation for all transitions" there is no such thing as a
>> SHOULD requirement. It's a suggestion. It sounds like a good one but it
>> needs to clarify known by whom and howmuch work the WG is expected to do
>> to find implementations. (e.g. once a year or so I come across an XQuery
>> implementation entirely done outside the WG that none of us knew about,
>> most often used inside a product or an organization)
>
> This material is not present in the latest draft. But describing the  
> strength of a statement marked SHOULD is ultimately an editorial  
> judgement. I'll raise an issue to clarify it, whatever it is.

Hmm. Looks like this is resolved by comments later in the document. No  
specific change applied.

>> 2. "Every document published as part of the technical report development
>> process must be a public document" does this mean no more Member-only
>> working groups?  Or does it mean the documents must be public after
>> being published?
>
> "Published" in the document means put on /TR. So it has nothing to do  
> with how groups
> choose to develop their work.
>
> I'll check that this meaning is
...clear.

Added "Please note that publishing as used in this document refers to  
producing a version which is listed as a W3C Technical Report on its  
Technical Reports page http://www.w3.org/TR." to the beginning of the  
document, and again in the definitions section.


>> 8. "Note: Last Call Candidate Recommendation is the state referred to in
>> the W3C Patent Policy [PUB33] as "Last Call Working Draft"
>> No it isn't. lCCR didn't exist when the patent policy was written. I'm
>> not sure what is meant here, but I think it's, "A specification at Last
>> Call Candidate Recommendation shall be considered to be a Last Call
>> Working Draft for the purposes of the patent Policy [ref]." But LCCR is
>> certainly not what was meant when the patent policy was drafted. This is
>> obvious to us now, but not to someone outside W3C.
>
> OK. I believe this is editorial but a good suggestion. I'll make the  
> change.

Actually I think the text already there in the most recent drafts reflects  
better what you suggested. No further change made.

>> 9. What is meant by "Note: Last Call Candidate Recommendations will
>> normally be accepted as Recommendations."? Does that mean that once we
>> get to Last Call Candidate Recommendation we've also reached
>> Recommendation? If so why is W3C Recommendation a separate step?
>
> No, it means that they will *normally* be the same content. The separate
> steps represent a few checks that attempt to avoid publishing things as
> Rec that we will regret later.

The wording in the Maturity Levels section had been changed slightly. No  
further change.

>> 15. These steps do not include Proposed Edited Recommendation - is the
>> omission deliberate?
>
> Which steps?

I assume you mean the steps listed in the introductory material. Yes it is  
deliberate. But see also Issue 95.

>> 16. the list of maturity levels does not include Proposed
>> Recommendation, nor Edited Recommendation, and presumably should.
>> Currently, 7.4's ordered list is the first mention of Edited
>> Recommendation after the table of contents.
>
> Was fixed.
>
>> 17. "The Director must inform the Advisory Committee and Working Group
>> Chairs when a Working Group's request for a specification to advance in
>> maturity level is declined"
>> It would make sense to require that the reason for the refusal is also
>> disseminated to the AC and Chairs. For a public WG it should also be
>> made public.
>
> I'll raise an issue. I agree with the proposal.

Created issue 94

>> 22. "To publish an Edited Recommendation as a W3C Recommendation" I
>> don't think this is right. I think you mean, "To publish a Last Call
>> Candidate Edited Recommendation as an Edited Recommendation" but given
>> the lack of definitions of these terms I can't be certain.
>
> I actually mean to say that you can publish it as a Proposed  
> Recommendation without returning to an earlier stage. I'll raise an  
> issue on this.

I created issue 95 https://www.w3.org/community/w3process/track/issues/95

>> 29 "Working Group must report errata page changes to interested parties"
>> and "For instance, the Team might set up a mailing list per
>> Recommendation where a Working Group reports changes to an errata page."
>> This is interesting and not something I've encountered before.
>> presumably the mailing list should be public (i.e. anyone can subscribe)
>> and have public archives?
>
> This whole thing is "...according to the Team's requirements." While I  
> would love some consistency and clarity from the Team on that, as I  
> understand the current requirements are "we don't really care enough to  
> worry about this". Sadly, that seems OK to me for the present, as it  
> apparently has been for the last decade.

I raised Issue 96 to track this, although I don't think it should be a  
gating factor on this version.  
https://www.w3.org/community/w3process/track/issues/96

>> 33. Ok, now we get to a definition of conformance, damn you Charles! :-)
>
> I reject damnation except from verified saints from my approved list.  
> Which is unavailable :P
>
>> Hmm, no, we don't. It just looks like it. "turns conforming data,
>> processors, or other conforming agents into non-conforming agents"
>> . how do you turn data into an agent?
>> . what does it mean to be conforming in the first place?
>> . what is an agent?
>
> clarified the editorial confusion.

Which will be clear in the next Editor's draft, that should be available  
shortly after this mail.

>> This text has some informal helpfulness but the difference between the
>> first and third bullet points is unclear - how would a change to the
>> specification " in such a way that an agent whose conformance was once
>> unclear becomes clearly conforming or non-conforming" (I think you mean
>> clearly conforming or clearly not conforming)
>
> Although I believe the statement says what you think I mean, I could  
> equally remove the "clearly". I'll do one or the other.

I changed it to "clearly either…"

>> 34. "The modified Recommendation is published according to the Team's
>> requirements, including Publication Rules [PUB31] and the Requirements
>> for modification of W3C Technical Reports"
>> So we go to http://www.w3.org/2003/01/republishing/ and find that only
>> the *first* class of change and not the second are permitted.
>> I *think* what is going on is that you are proposing relaxing this,
>> consistent with current practice (fixing obvious typos, adding a
>> non-normative note, etc being allowed). I support this, and would lke to
>> see the "republishing" document updated too, of course.
>
> the "republishing" document is something the Team wrote. The Process  
> sets the rules, so it *should* be updated.

As noted above I raised Issue 95, because I think this still needs  
clarification. I'll follow up in that thread.

cheers

Chaals

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

Received on Wednesday, 23 April 2014 16:19:44 UTC