Retire Proposed Recommendation #868
Conversation
frivoal
added
Needs Review
Needs AB Feedback
Proposed Recommendation is only a transitional phase. Nothing stays there: either the transition is approved and the spec goes to REC, or it's not and it reverts to a lower maturity. The things that happen during PR are useful, but they don't really depend on there being an explicit phase with an explicit publication, so we can simplify things by folding all of this into the transition from CR to REC, without a distinct phase. Part of w3c#861
|
Looks like a good draft (on a skim of the github diff rather than a very careful review, so faar). |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
All accepted. Thanks! |
|
From the AB's last meeting:
|
frivoal
added
Agenda+
This is not specifically on the Working Group, so including it in the list was odd. The requirement itself is unchanged.
| For example, to make [=substantive changes=] to a [=technical report=] | ||
| prior to publication as a [=Recommendation=], | ||
| it would need to go through a new [=Update Request=], | ||
| be republished as a new [=Candidate Recommendation=], | ||
| and fulfill the criteria for advancement. |
There was a problem hiding this comment.
I find this example quite confusing to read now. I think there may be an unstated assumption that the technical report was a Rec before the substantive changes were made, and the goal is publication as a new Rec version?
There was a problem hiding this comment.
No, the assumption is that on a CR to REC transition, the Team cannot just change stuff an publish. Any normative change needs a WG decision, and be published as a CR first (so as to trigger patent exclusion opportunities).
I guess what's confusing here is that "those other conditions must also be re-fulfilled" is in practice not really something you can do in the middle of an AC Review wrap-up, so the realistic way to deal with this is to send the document back for further work, not to approved it with changes integrated (and extra steps to make that possible).
There was a problem hiding this comment.
Oh, okay. How about:
| For example, to make [=substantive changes=] to a [=technical report=] | |
| prior to publication as a [=Recommendation=], | |
| it would need to go through a new [=Update Request=], | |
| be republished as a new [=Candidate Recommendation=], | |
| and fulfill the criteria for advancement. | |
| For example, if [=substantive changes=] to a [=technical report=] | |
| are requested when assessing the transition from | |
| [=Candidate Recommendation=] to [=Recommendation=], | |
| the technical report would need to go through a new [=Update Request=], | |
| be republished as a new [=Candidate Recommendation=], | |
| and that new version would need to fulfill the criteria for advancement. |
| <dt> | ||
| <dfn export id="RecsPR" lt="W3C Proposed Recommendation | Proposed Recommendation | PR">Proposed Recommendation</dfn> (<abbr>PR</abbr>) |
There was a problem hiding this comment.
Would it be worth keeping a stub definition for this, in case people are looking at old PRs on /history and want to know what they are?
There was a problem hiding this comment.
The id is reserved, so that links will still land in a reasonably relevant place. That place does not mention Proposed Recs explicitly though:
https://github.com/w3c/process/pull/868/files#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985R3885
I see your point, but at the same time, because Proposed Recs are only an transient state, it's not that common for people to be reading them once the relevant AC Review has closed.
We don't keep a stub definition for Last Call Working Draft either.
Maybe we could add an Appendix to the Process listing all the TR statuses that no longer exist, with pointers to older version of the Process that still had them? Not sure if this would be useful, or just make the Process longer for little benefit.
There was a problem hiding this comment.
| Alternatively, the desired changes can be introduced as non-substantive amendments | ||
| using the process for [[#revising-rec|revising a Recommendation]]. | ||
| However, they cannot be directly integrated between [=PR=] and [=REC=], | ||
| However, they cannot be directly integrated between [=CRS=] and [=REC=], |
There was a problem hiding this comment.
Except for removal of at-risk features.
There was a problem hiding this comment.
True. However, is that too much detail for an example? We could add it as a parenthetical, but I am not sure if it really brings clarity.
There was a problem hiding this comment.
I don't think it's too much detail. Without mentioning this, it looks like the example contradicts the Process, and that could be confusing for some group later if they do want to remove at-risk features at this stage.
| and <em class=rfc2119>must not</em> include any such marking | ||
| if not already present. | ||
|
|
||
| If all the criteria above are fulfilled, |
There was a problem hiding this comment.
It would be worth being explicit that the Team's trigger to check if the criteria have been fulfilled is a WG Decision to request advancement.
There was a problem hiding this comment.
It's a little hard to see in the diff because there are a lot of added/removed lines in between, but if you look at the built version, isn't that already made clear by the first sentence in the section?
https://pr-preview.s3.amazonaws.com/frivoal/w3process/pull/868.html#transition-rec
There was a problem hiding this comment.
I did see that sentence, but for myself, I don't think it's clear that a WG requesting advancement to REC is synonymous with a WG Decision to request advancement.
It needs to be unambiguous to Chairs what is required; the alternative is that it could be seen as being okay if a WG has some kind of discussion without a clear assessment of consensus and the Chair then makes a request for advancement on behalf of the WG; that would bypass any WG decision policy, for example.
As discussed in #861, the Proposed Recommendation phase of the REC track exists only to support an AC Review during the transition of a document from CR to REC. We can simplify the Process a good deal by doing away with Proposed Recommendation entirely, and doing the AC Review on the CR that we want to promote to REC. Then, if the AC Review is successful (in addition to the other criteria), we could publish the REC directly.
This Pull Request does just that. It keeps all the criteria that were present at the CR→PR transition, as well those of the PR→REC transition, and combines them into a CR→REC transition.
This allows for a simplification of terminology, a simplification of Process text, a reduction in the number of states described in the REC track diagram, and a reduction of work needed by the WG and the Team (one transition to request instead of two, one less publication to make); all without any changes about what is expected of a Recommendation.
Preview | Diff