- From: Jeff Jaffe <jeff@w3.org>
- Date: Mon, 17 Feb 2014 08:38:09 -0500
- To: Charles McCathie Nevile <chaals@yandex-team.ru>, Steve Zilles <steve@zilles.org>, public-w3process@w3.org, ab@w3.org
On 2/17/2014 6:05 AM, Charles McCathie Nevile wrote: > On Mon, 10 Feb 2014 22:26:38 +0100, Jeff Jaffe <jeff@w3.org> wrote: > >> On 2/10/2014 1:08 PM, Steve Zilles >> wrote: > >>> Jeff, >>> you raise some good questions. See comments inline below. > >>> From: >>> Jeff Jaffe [mailto:jeff@w3.org] >>> Sent: Friday, February 07, 2014 8:05 AM >>> >>> To: Charles McCathie Nevile; >>> public-w3process@w3.org; ab@w3.org >>> >>> Subject: Re: New draft - please review >>> >>> >>> 1. I think the >>> description is a bit confusing around 7.4 (CR) and 7.4.1 >>> (Revised CR). It might be useful to combine them somehow into >>> one Section. Some of the confusions are: >>> >>> >>> * There is a different list of "MUST do's". >>> >>> SZ: >>> In particular, updates on Dependencies and the plan to show >>> “adequate Implementation Experience” are not required. > > Yes. The transition to CR from Working Draft is a step different to > that of republishing a CR. Ditto for revising a WD. The request for a > "revising a CR" section was an explicit part of ISSUE-59. > > I'm not wedded to it except that it appears to have different > requirements to making a transition into CR, so seems to make sense. > >>> * Revised CR is not a formal state, yet it has >>> its own treatment. >>> >>> SZ: >>> perhaps this can be just the end of the section on CRs or >>> alternatively, the section might be called “Revising >>> Candidate Recommendations” which is a process not a state. > > Indeed. > >>> * In Section 7.4 a possible next step is "Return >>> to CR", but you really mean "Become Revised CR". >>> >>> SZ: >>> rather than have a “revised CR” there should just be “CR”s. >>> To this end, I suggest changing, “the Director must approve >>> the publication of a revised Candidate Recommendation” to, >>> “the Director must approve the re-publication >>> of a Candidate Recommendation.” This does not introduce a >>> new category of document (which is unneeded as far as I can >>> see). > > The wording has been changed in section 7.4.1 to clarify this, and I > have given it a further tweak along the lines Steve proposes here, but > using "permission to publish a revision of a CR". > >>> I don't have a specific proposal to fix, I just note it is a >>> bit confusing. > > Well, the process can be… > > I believe it is very helpful when thinking of this to pick a concrete > example and work out what you will do. Trying to check an algorithm > with no data is especially confusing, in my experience. I'm not sure what you mean by trying to check an algorithm with no data. Should I understand what you mean, or should I just wait for the next draft and see if I am still confused? > >>> 2. Once entering PR, I assume that the WG can no longer drop >>> any features. If I am correct, it is not clear to me that >>> this is clear in the document. > > You are, and I agree it should be clearer > >>> SZ: >>> I agree with your point and suggest, in section 7.5 >>> changing, >>> >>> >>> “may >>> remove features identified in the Candidate Recommendation >>> document as "at risk" without repeating the transition to >>> Candidate Recommendation” >>> >>> to >>> “may >>> remove features identified in the Candidate Recommendation >>> document as "at risk" before republishing the Candidate >>> Recommendation as a Proposed Recommendation, but must not >>> make any subsequent changes to that Proposed >>> Recommendation.” > > I believe this has since been addressed by less ambiguous wording in > section 7.4.1, and by the addition in the upcoming draft of explicit > statements in the Proposed Recommendation and Recommendation sections > saying there cannot be changes from PR to REC. > > cheers > > Chaals >
Received on Monday, 17 February 2014 13:38:20 UTC