Clarify what the expectations are for advancing to CR #214
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1916,9 +1916,12 @@ <h4 id="maturity-levels">6.1.2 Maturity Levels</h4> | |
| corresponds to the "Last Call Working Draft" discussed in the Patent Policy.</li> | ||
| </ul> | ||
| </dd> | ||
| <dd><strong>Note</strong>: Advancing to Candidate Recommendation indicates that | ||
| no further improvement is expected without additional implementation experience and testing. | ||
| A Candidate Recommendation is expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation, | ||
| and acceptable as such if and when the requirements for further advancement are met. | ||
| Announcement of a different next step <em class="rfc2119">should</em> include | ||
| the reasons why the change in expectations comes at so late a stage.</dd> | ||
| <dt id="RecsPR">Proposed Recommendation</dt> | ||
| <dd>A Proposed Recommendation is a document that has been accepted by the W3C Director as of sufficient quality to become | ||
| a W3C Recommendation. This phase triggers formal review by the Advisory Committee, who <em class="rfc2119">may</em> recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned. Substantive changes <em class="rfc2119">must not</em> be made to a Proposed Recommendation | ||
|
|
@@ -1961,6 +1964,13 @@ <h4 id="maturity-levels">6.1.2 Maturity Levels</h4> | |
| abandoned without producing a Recommendation.</dd> | ||
| </dl> | ||
|
|
||
| <p>Only sufficiently technically mature work should be advanced. | ||
| <strong>Note:</strong> Should faster advancement to meet scheduling considerations be desired, | ||
|
There was a problem hiding this comment. This was my wording originally, but on re-reading, and thinking about the change of Should faster advancement to meet scheduling considerations be desired to If faster advancement to meet scheduling considerations is desired, There was a problem hiding this comment. How about "to advance faster" ? If nobody wants to do that, it doesn't matter, and if they do we don't need to complicate the text. There was a problem hiding this comment. I'm relatively indifferent between the existing phrasing and the alternative one proposed by @nigelmegitt . As for the one suggested by @chaals, would not object to it, but I like it less. Sure, it's shorted, but it hides the fact that advancing faster is a matter of choice. |
||
| this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring | ||
| less stable features to other technical reports.</p> | ||
|
|
||
|
|
||
|
|
||
|
There was a problem hiding this comment. Disagree with this addition, as it reflects hope over realpolitik. A group may rationally and sensibly opt to bundle features and hold back "technically mature" features in order to offer a synchronized package of mature features. There was a problem hiding this comment. NB: that disagreement refers to the whole insertion, " The decision to advance to a new maturity level must be made solely based on the technical maturity of the work. There was a problem hiding this comment. I don't understand what you're saying. (a) you think groups should push immature features to CR? or (b) they should hold back and wait until all they stuff they wants is mature (which doesn't conflict with this statement) or (c) something else? There was a problem hiding this comment. I am confused too, for the same reason as @dwsinger There was a problem hiding this comment. The latter (b), which is contradicted by "The decision to advance to a new maturity level must be made solely based on the technical maturity of the work" There was a problem hiding this comment. Nonetheless, I find the addition unduly constraining. There was a problem hiding this comment. I just don't get it:
(I don't object to removing the note for the sake of making progress, since it is indeed just a note, unless the intent is to allow advancing things that are not ready). There was a problem hiding this comment. Maybe I am just dense, but what alternative is there other than:
The note says: ”if you don't want to do 2, you can do 1“. Unless you're claiming that 3 is a legitimate thing to do, I just don't understand the pushback. There was a problem hiding this comment. Suggest s/may/can/ in the note, but otherwise agreed with frivoal/nigel/dsinger : unless you're arguing for #3 (advancing things that are not ready in pursuit of preconceived deadlines) I don't understand the objection. There was a problem hiding this comment.
Good suggestion, which I don't expect to change the opinion of anyone already in favor of this, so I've updated the text accordingly: f5e96b2 |
||
| <p>Working Groups and Interest Groups <em class="rfc2119">may</em> make available "Editor's drafts". Editor's drafts have | ||
| no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are | ||
| their contents endorsed in any way by W3C.</p> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No further substantive improvement?
WGs typically re-read their specs and make editorial improvements, and that should fall within the range of what is expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I was wondering about something like this.
The flip side is that just because editorial improvements are allowed doesn't mean that they are expected, and since we expect CRs to be acceptable as RECs, we should mostly not enter CR when things are unreadable and need massive editorial improvements.
Then again, if we adopt the suggestion you propose, combining it with the rest of the text, it means that we're supposed to enter CR with high quality prose that would be acceptable as a REC, but that this is not incompatible with having further plans for editorial improvements, which sounds reasonable to me.
I'll ponder that for a short white, but unless someone pushes back, I'll probably make this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the key word here is expected. No, we don't want CRs that have known editorial issues either. On the other hand, this sentence is clearly about the technical content. No technical improvement is expected without...?