Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed Recommendations aren't useful in the same way other maturity stages are #861

Open
frivoal opened this issue Apr 30, 2024 · 5 comments
Labels
Agenda+ Marks issues that are ready for discussion on the call Topic: Simplifications

Comments

@frivoal
Copy link
Collaborator

frivoal commented Apr 30, 2024

Unlike (FP)WD, CR(S or D), and RECs, Proposed Recommendations aren't long-lived stages on the Recommendation track.

They only exist for the purpose of supporting an AC Review about the transition from CR to REC. The Process explicitly disallows making substantive changes to Proposed RECs, and you need to cycle through more CRs (or WDs) if you want to change things.

It seems to me that we could do away with Proposed RECs, while keeping the associated AC Review. It would just apply to a CR instead of a PR. We'd still have an "AC Review to propose advancement to Recommendation", and it would still apply to a CR that has satisfied all the criteria for advancement, but we wouldn't need a distinct publication.

We have done similar things before:

  • Registries go directly from Candidate Registry to Registry and there's no "Proposed Registry"
  • Notes get elevated to Statement without going through a specially named publication to which the AC Review applies (and they still have a bunch of criteria to fulfill).
  • We used to have a special kind of Working Draft distinctly identified as Last Call Working Draft about which WGs needed to demonstrate wide review, before advancing to CR or going back to regular Working Drafts. We've keep the wide review requirement, but discontinued the transitional LCWD stage.

This would allow us:

Also, while I suppose we could deal with these two independently, I think it would make sense to also look into a similar merger of candidate ammendments with proposed amendments. This could be part of the simplification of .3.11.5. Incorporating Candidate Amendments requested in issues like #590, #589, or #700

@css-meeting-bot
Copy link
Member

The Revising W3C Process CG just discussed #861.

The full IRC log of that discussion <plh> subtopic: #861
<plh> Github: https://github.com//issues/861
<cpn> Florian: I'm looking how to simplify the process
<cpn> ... The Proposed Rec phase is useful, we do checks, poll the AC
<cpn> ... Less useful may be the publication of the PR itself. We could do all those things on the CR
<cpn> ... Before, we had last call CR, as a transitional phase. We removed it 10 years ago?
<cpn> .... Other types of report, Registries, Statements, etc don't have a PR phase
<cpn> ... I have a draft PR, it would reduce amount of text without the meaningfully changing things
<cpn> ... Let me know if it's a bad idea. Otherwise I'll propose a PR
<plh> q?
<fantasai> +1 from me https://fantasai.inkedblade.net/weblog/2011/inside-csswg/process
<cpn> +1 from me
<cwilso> +1
<TallTed> +1 to see the PR
<cwilso> q+
<cpn> Florian: OK, will make the PR. It also will help simplify the diagrams
<plh> ack cwilso
<plh> q+
<cpn> cwilso: The state isn't useful, but the transition point is. There are gates on PR, but really they're on advancing to Rec
<plh> ack plh
<cpn> Florian: Yes, all those need to stay
<cpn> PLH: The publication is a public signal. But there's already public confusion about the different document types we have in general
<cpn> Florian: If we want to communicate, we could write a blog post
<plh> ack fan
<cpn> PLH: If people don't care, we can remove it, but if they do we'd need to look deeper
<cpn> Fantasai: This simplifies the process, but it's a major change to how the Process feels. We should propose it to the AB then the AC before including in the draft Process
<cpn> Florian: Makes sense. Drafting the PR will help people judge, but happy to wait for feedback before landing it

@chaals
Copy link
Contributor

chaals commented May 10, 2024

TL;DR: We've been here before

Some history (and some pointers for archaeologists)

In re-establishing work on the process document, during the hiatus between work being abandoned around 2007 and taking up a new effort half a decade later, the drafts I proposed (There was a public record for about half a year by then) did not have the PR phase - much as you are proposing now.

It was reinstated starting on 2014-02-05...

The issue was managed in Tracker as ISSUE-77, and you can follow the CG email archives for a substantial amount of the discussion (I don't recall exactly when the AB agreed to have at least some of the discussion in public, maybe around mid 2013...)

@frivoal
Copy link
Collaborator Author

frivoal commented May 13, 2024

Thanks @chaals. For anyone else looking into this, here the state of that historical draft right before Proposed Recommendation was reinstated: https://lists.w3.org/Archives/Public/www-archive/2024May/att-0001/tr.html, extracted from the mercurial repository.

At first glance, there appears to be a significant difference between that and what I'm proposing now: the earlier attempt seemed to move from CR to REC once the transition request was successful, but prior to the AC Review. The REC was then marked as provisional, and the AC review was conducted on the basis of that document. Then, somehow (asking how was part of what led to PR being reinstated), if the AC review is successful the REC then becomes no longer provisional. Part of the pushback, as I understand it, was that this provisional REC was not all that different from a Proposed REC, and that in that case we might as well keep the familiar name and the explicitly documented transitions.

Here, I'm proposing that we keep the spec at CR until all conditions to be a REC are met (including AC Review), so there's no transitional or provisional state. It'll be clearer once as I post a Pull Request, which I intend to do shortly.

frivoal added a commit to frivoal/w3process that referenced this issue May 13, 2024
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
frivoal added a commit to frivoal/w3process that referenced this issue May 13, 2024
frivoal added a commit to frivoal/w3process that referenced this issue May 13, 2024
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
frivoal added a commit to frivoal/w3process that referenced this issue May 13, 2024
@chaals
Copy link
Contributor

chaals commented May 13, 2024

Yeah, the approach to a new process went through some iteration, but the goal was actually the same.

It might be worth skimming the discussion, but I suspect not much changes, except if we have a simpler process to get more Recomendations there are people like me who will be pleased, and people who seem to think we shouldn't consider it a goal to publish Recommendations, who will not be pleased by any progress toward that goal.

@frivoal
Copy link
Collaborator Author

frivoal commented May 13, 2024

first take available at #868

@frivoal frivoal added the Agenda+ Marks issues that are ready for discussion on the call label Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agenda+ Marks issues that are ready for discussion on the call Topic: Simplifications
Projects
None yet
Development

No branches or pull requests

3 participants