Re: Process chapter 7 draft...

On Tue, 04 Mar 2014 17:05:40 +0100, Steve Zilles <steve@zilles.org> wrote:

> Charles,
> This is an admirable document. Thank you for all the effort you put into  
> creating a simpler, clearer, more flexible process.

Well, thanks to everyone who put the effort in to help make what I  
produced worth having.

> I have a few suggested fixes, mostly editorial, I hope.
>
> Section 7.2.2, penultimate paragraph
> /whereas for later stages/whereas for maturity levels beyond Working  
> Draft/
> [the term "later stages" is undefined and unnecessary.]
> Also put a comma after "fairly mechanical" and change the following  
> comma (after "automatic") to a semicolon.

The paragraph changed already, based on similar review by Ann. But "later  
stages" is normal english, so I don't propose to make the change.

> Section 7.4, Possible next steps
> I thought we agreed to drop the terminology, "revised Candidate  
> Recommendation" and to use "re-publish  as a Candidate Recommendation"  
> to avoid creating a new "maturity level"

see next answer

> Section 7.4.1, final paragraph
> /the publication of a revised Candidate Recommendation/the  
> re-publication of the Candidate Recommendation/

I've been happy to use the word "revised" (since it is a normal english  
word) separating it in links and by not title-casing it. Do you think we  
need more

> Section 7.5, under "a Working Group"
> Bullets 3 and 4 exclude comments by "Advisory Committee representatives"  
> without pointing to the "dissent" bullets in section 7.6 which is where  
> such comments are handled. I suggest a forward reference to this  
> section, such as "Advisory Committee representative issues are handled  
> in section 7.6."

I've clarified this, based on review comments by Ralph, to note that the  
questions that are excluded are those which are part of the formal AC  
review. I think that is enough in practice.

> Section 7.5, "a Working Group", bullet 5
> /in the Candidate Recommendation document as "at risk"/in the Candidate  
> Recommendation documented as "at risk" prior to publication as a  
> Proposed Recommendation/
> [to resolve the implication that "at risk" features can be dropped from  
> a PR.]

I went with "may have removed features identified in the Candidate  
Recommendation document as "at risk" without republishing the  
specification as a Candidate Recommendation."

I sometimes worry about this being used to remove features that others  
relied on having. Accessibility features have raised this issue in  
practice, but I think (and so far the accessibility cases have generally  
shown) there are enough checks in place such as the ability to appeal a  
transition if there was dissent in the WG.

> Section 7.6, bullet 3
> /In this case,/In the case of unsatisfied dissent,/
> [to make it clear that you cannot appeal if your dissent is  
> satisfactorily resolved.]
> The same change should be made in the final paragraph of 7.9 as well.

If you appeal, your dissent was not satisfactorily resolved. As reinforced  
by the fact that your appeal got the necessary backing from other AC reps.

I don't think this should be changed, since there is no formal way to  
determine what "satisfactorily resolved" means - it implies that the  
director and the dissenter(s) no longer disagree - in which case there  
will be no appeal.

> Section 7.7.2, first bullet of 3rd paragraph
> /identifying it as the basis for a Request for  
> Recommendation/identifying it as a Proposed Edited Recommendation/
> [I believe that we dropped the "Request for Recommendation" label, but I  
> am not sure what should replace it here. The original process  
> distinguished the PER because it does not trigger a new Exclusion Call,  
> as far as I know. But adding PER creates another "maturity level" (and  
> another state in the diagram).]

I don't think it creates a new state. Essentially it creates a new arc  
 from Rec to Proposed Edited Rec. However, I have left that out, since the  
original state diagram describes the "expected" process from nothing to  
Rec for documents that succeed. For the same reason I left out the  
possible state of Note.

But I made the substitution.

> Section 7.7.2, bullet 3
> /Should address all errata./Should address all errata known at the time  
> of the request./

I used "should address all recorded errata". It isn't a must requirement,  
and given that I find it hard to imagine people will get hung up on things  
the working group apparently didn't know at the time.

> Section 7.8, paragraph 2
> /In order to publish a Note/In order to publish a Note,/
> [add comma]

Done.

cheers

Chaals

> Steve Z
>
> -----Original Message-----
> From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru]
> Sent: Monday, March 03, 2014 10:29 AM
> To: W3C Advisory Board
> Subject: Process chapter 7 draft...
>
> Hi,
>
> please note that the current draft, which you should consider is  
> https://dvcs.w3.org/hg/AB/raw-file/7b98193bc9d9/tr.html
>
> At 8.30 in the morning I believe Jeff will be assuming you have read it  
> if you plan to participate in the discussion, and so I will also make  
> that assumption. It's about 4500 words - or around 2/3 the current  
> version.
>
> As far as I can tell, the Task Force has agreed to propose this draft to  
> the AB as suitable to offer to the AC (perhaps for a new last call - in  
> any event the discussion of how we implement the shift from one process  
> version to another is tangential to the content of this chapter).
>
> I expect to produce another draft tonight, with half a dozen minor (a  
> few letters or words) editorial changes based on Ralph's recent review,  
> as per http://www.w3.org/mid/op.xb5q9sd8y3oazb@chaals.local assuming  
> there are no objections to them from the task force.
>
> You can see changes by following the changeset links at  
> https://dvcs.w3.org/hg/AB/ (They show HTML lines added/removed, but it's  
> easy enough to read the differences even if your only understanding of  
> HTML is "there is the text, and funny things between pointy brackets  
> that do the magic" :) ).
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>        chaals@yandex-team.ru         Find more at http://yandex.com
>
>


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

Received on Sunday, 9 March 2014 23:55:01 UTC