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

On Tue, 2014-04-22 at 21:40 +0200, Charles McCathie Nevile wrote:
> Hi Liam,
Hello!

> Can you say what version you reviewed, since it seemed not to be the  
> current one even when you sent this.
Sorry - it was a link Coralie forwarded -
http://lists.w3.org/Archives/Public/public-w3process/2014Mar/0005.html


> In several cases I have apparently rejected your comments - i.e. I don't  
> propose to do anything with them. If you want an issue raised, feel free  
> to do it in the w3process tracker. Where I believe there is an issue I  
> will raise one myself, as noted inline.

i'm fine with all the actions you've taken.

To answer your questions,

> > 4. "Every document published as part of the technical report development
> > process must clearly indicate its maturity level, and must include a
> > section about the status of the document."
> > What about documents that are already on /TR and are not yet at Rec?
> > Their maturity level indicators will now be misleading, but the previous
> > sentence says we won't change documents on /TR.  Therefore, we should be
> > careful never to change the meaning of a maturity level.
> 
> Why would they be misleading? The changes are that "Last Call" goes from
> having a defined meaning to being a historically meaningful term, and
> Candidate Recommendation assumes a certain amount of that meaning. All
> documents are published with a date, and a pointer to the operative
> process document, but even so, the practical differences seem unimportant
> to understanding what you are getting.

Yeah, maybe you are right that it's not important in practice, OK.

[...]


> > 7. "An editor must be a participant, as a Member representative, Team
> > representative, or Invited Expert in the Group responsible for the
> > document(s) they are editing."
> > This could be read as excluding e.g. a hired professional writer from
> > editing a document, i.e. that in order to be called an editor, a person
> > must be a WG participant; or it could be read as meaning "at least one
> > of hthe editors must be a WG participant". In either case we could not
> > (publish XPath with this rule, because it's developed jointly with two
> > Working Groups. I know, I know, I'm being pedantic, but if we are
> > writing a process to cover what we do, etc etc...
> 
> Yeah, there are several situations where this (existing) process
> requirement is violated. It isn't clear to me that the rule should be  
> changed, although it is also unclear how to publish a document jointly.
> 
> This is probably worth addressing seriously, although I believe it is  
> orthogonal to any changes made so far, and could be done in a revision  
> along with other changes to the Process.

I think the "must" should be a "should". But I can live with it.

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

Then I think the text should say, Last Call Candidate Recommendations will
normally be published as Recommendations with no substantive changes.

But I prefer active rather than passive statements, so,

W3C Will not normally permit substantive changes to documents between
Last Call Candidate Recommendation and Recommendation.


> > 11. "Working Groups and Interest Groups may publish "Editor's drafts""
> > Currently some groups publish these outside /TR; the Process should be
> > explicit about whether this is OK and under what circumstances.
> 
> As far as I am aware, and by definition "Editor's drafts", as opposed to  
> Working Drafts as defined by the Process, are all published outside /TR.

But the document defines "publish" to mean "on /TR"...

[...]

> > 13. "A substantive change" (7.2.1, definition) - this is an area where

[...]

> I *believe* this section has been rewritten since this comment,  
> invalidating the comment.
ok



> > 14. "W3C follows these steps} [...] "Possibly, Publication as an Edited
> > Recommendation"
> > Suggest expanding that to a separate paragraph, If the need arises to
> > incorporate errata or change a Recommendation for other reasons, a new
> > edition may be produced as an Edited Recommendation".
> 
> I prefer to leave the details to the relevant section (as with the rest of  
> the list of steps).
> 
> > 15. These steps do not include Proposed Edited Recommendation - is the
> > omission deliberate?
> 
> Which steps?

The ones in 7.1.1; there's nothing between
 5   Publication as a W3C Recommendation.
and
 6   Possibly, Publication as an Edited Recommendation

[...]

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

[...]

> > 21. I note that neither "7.4.2 Last Call Candidate Recommendation" nor
> > "7.4.3 Publication of a W3C Recommendation" explicitly requires sign-off
> >   from other Working Groups mentioned in the WG charter or charters (for  
> > a multiple-WG document) as having formal liaisons. This may help to speed
> > up the process but I am not sure it's an improvement.
> 
> Generally, a group would be expected to show as part of wide review that  
> it has got agreement from groups which are listed as having formal  
> liaisons or dependencies. The group is specifically required to state any  
> changes to dependencies at transition.

"liaison" doesn't seem to occur in the text...


> > 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 erturning to an earlier stage. I'll raise an issue  
> on this.

Thanks.

> > 24. Is it actually the Director who must address the comment, or the WG?
> 
> Where?

[[
the Director must publish the substantive content of the dissent to W3C
and the general public, and must formally address the comment at least
14 days before publication as a W3C Recommendation. 
]]


[...]


> > 28 "A Working Group should keep their errata pages up-to-date"
> > What does this mean?
> 
> It means the Working Group, unless there is some good reason not to do so,  
> is ordinarily expected to add reported errors to the errata page...

Is it OK for there to be a three-year delay? If not, what happens when
there is? (I don't think such a situation unusual)

[...]


> > how would such a change
> > not also be one that "turns conforming data, processors, or other
> > conforming agents into non-conforming agents"?
> 
> Example: When I wrote an SVG font in 1999, it was unclear from the (then  
> draft) specification where exactly the change from zero-down to zero-up  
> measurement on the Y-axis took place. Making that explicit may not have  
> changed conforming processors into non-conforming, or vice versa, since  
> until it was specified it is impossible to say if implementation  
> (including content) was conforming or non-conforming based on where they  
> assumed the change should take place.

Thanks - a clarification to the spec, in other words, that may or may
not cause problems with existing agents and/or documents, since the set
of implementations is generally unknown.


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

I see, thanks.

[...]

> 
> > 38. process bug
> >
> > In order to process an edited recommendation, a WG must show that the
> > document has received wide review... (7.4.3)... *before* publishing it.
> > How exactly do you do that?
> 
> However you want. Errata are public, the base document is public, the  
> changes allowed in a PER are relatively simple ones. You can publish  
> editors' drafts, delta specs, or make the case that the widely reviewed  
> cvs diff meets the requirement, depending on the circumstances.

Hmm, OK, in the past we've had to use the same criteria to get from PER
to Edited Rec as were used to exit CR.

[...]

Thanks for your careful responses.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Received on Thursday, 1 May 2014 05:35:19 UTC