living standard / candidate review snapshots need to address wide review issues

[npdoty]

Update requests have less strict requirements than transition requests. One side effect of this appears to be that Working Groups do not need to address issues raised in wide review in order to continue to make update requests and publish additional Candidate Recommendation Snapshots. For an increasing number of groups, Candidate Recommendation Snapshot is the final maturity level, and so this would (inadvertently, I assume) mean that a Working Group can finalize and continue to update specifications indefinitely without ever addressing issues raised in wide review. That would be a poor outcome for ensuring that W3C specifications reflect wide review and horizontal review.

As a practical matter, we would expect that the Team would use its discretionary approval to make sure that lingering issues are addressed, but the Process currently provides no guidance about that.

We should update the Process to indicate that issues must be addressed, even for groups using Candidate Recommendation Snapshots: either by formally requiring that for some Snapshot publication (maybe the current or next one), or for giving substantive guidance to the Team that they should evaluate open issues when determining whether to approve update requests.

[npdoty]

In the meantime / as a backdrop, I would expect that if this practice were taking place, we would expect to start seeing Formal Objections to Update Requests, or to the Team's decision to approve an update request. But that doesn't seem like the preferred way to go: it adds the extra cost of handling more Formal Objections, and it adds an unnecessary burden (to those raising issues or horizontal review groups generally) to making sure that raised issues are addressed.

[frivoal]

I don't think we should require that all view review comments have been addressed: it is a work in progress, and adding that requirement would be a lot more likely to dissuade people from publishing at all, rather than ensure exhaustive fixes. However, some exhortation to be processing the issues filed, and to have at least addressed some, would seem appropriate, as just flat out ignoring these comments isn't ok.

Not sure where to draw the line, but maybe we don't have to be to precise, and can indeed rely on team verification to judge whether a good faith effort at addressing issues is ongoing or not.

[michaelchampion]

rely on team verification to judge whether a good faith effort at addressing issues is ongoing or not.

Right. The whole point of "living standards" is to reduce the bureaucracy and politics required to get a reasonably authoritative draft to those implementing and deploying a spec. This depends on "wide review" of DEPLOYED specs by users as well as spec-writers and implementers. It also assumes rapid iteration to fix real-world problems.

Yes, there is a potential for abuse, e.g. continuing to publish specs even if they are getting serious issues raised by horizontal review. I think that's where the Team comes in: They are supposed to be expert and neutral enough to recognize such situations, and with enough authority stop publishing truly problematic specs as if they were authoritative. Or stop continuing to support WGs that abuse the process.

Trying to fix such corner cases in the Process itself adds to the perceived "bureaucracy", and will drive more work other venues.

[npdoty]

If the intention is to rely on the Team's judgement that open issues raised in wide review are not inappropriately lingering, then the Process should say so.

Under the current text, I'm not sure the Team is actually even supposed to take that into consideration, but can consider Formal Objections, and I don't think we need even more of the Process to rely on filing of Formal Objections.

[michaelchampion]

The lack of Formal Objections is essentially what "consensus" means in the Process. 🤷

I don't think the Process can anticipate all the reasons for not advancing a spec. It was traditionally the Director's judgment call. That judgment has mostly moved to the Team collectively, under the authority of the CEO.

[npdoty]

Having addressed issues or not is the kind of thing that shouldn't be too difficult to describe in a Process document, even when it relies on judgement. For example, the W3C's Process already has that requirement for transition requests, where it's a single bullet point.

[dwsinger]

we can maybe require that they consider all open issues and make a 'decision' not to address some when publishing a specific update; that makes it subject to someone formally objecting, no? or maybe we could even say that not addressing an issue in an update is implicitly a decision not to do so, and such an (implied) decision can be formally objected to

[michaelchampion]

Sorry, I think I misunderstood the issue. I don't have any concerns about Update Requests being required to meet the Transition requirements

[plehegar]

[[ Florian: is this relevant to the WHATWG MOU?

PLH: no

cwilso: yes

plh: what worries me is Mike Champion's last request, that update requests be subject to the same requirement as transition requests.

florian: ah yes. I Don't think we want to require everything be addressed; that would make it difficult to do CR updates.

florian: it's not clear that the team has the ability to say "you have made progress on issues that you care about, but ignored everything that others have reported, so your update request is denied"

+1 to florian florian: something along those lines would be desireable. plh: we did not introduce a requirement to address issues during the update requests, but we did introduce requirements to at least note which issues are flagged as needs resolution. [Add horizontal-review restrictions on transition](https://github.com/w3c/transitions/commit/dcdf174751d5338cc1e437b756f4045ff85e9446) ]] https://www.w3.org/2023/09/27-w3process-minutes.html#t04

[michaelchampion]

plh: what worries me is Mike Champion's last request, that update requests be subject to the same requirement as transition requests.

That's @npdoty's "request", I just said I don't have any concerns about it. I said the Team should make sure corner cases in the Process aren't exploited, @npdoty asks for more explicit Process language about this scenario, and I could live with that.

[npdoty]

My request was one of two things:

• either by formally requiring [addressing issues] for some Snapshot publication (maybe the current or next one),
• or for giving substantive guidance to the Team that they should evaluate open issues when determining whether to approve update requests.

Those are less strong than applying all the same requirements of Transition requests, although that would also satisfy this issue.

[css-meeting-bot]

The Revising W3C Process CG just discussed CR Snapshots need to address wide review issues, and agreed to the following:

• RESOLVED: Merge PR 787

The full IRC log of that discussion

<fantasai> Subtopic: CR Snapshots need to address wide review issues
<fantasai> github: https://github.com/w3c/w3process/issues/781
<fantasai> PR: https://github.com/w3c/w3process/pull/787
<fantasai> fantasai: People inside the group can object to publishing a CRS, but people outside the group can be ignored indefinitely
<florian> q+
<fantasai> fantasai: so this trying to fix this by giving the Team some discretion in denying a CRS
<fantasai> Changes: https://github.com/w3c/w3process/pull/787/files
<florian> fantasai: we already have CRD, which people can publish at will
<fantasai> florian: Fact that ppl can ignore issues is not true for transition requests (changing stage)
<fantasai> florian: This doesn't make it a requirement to address all the issues, but sets expectation that you should make some progress on such issues, and allows Team to deny CRS if not
<florian> fantasai: any other opinion?
<fantasai> TallTed: Just one grammar fix
<fantasai> florian: pre-existing wording, but could fix as we go?
<fantasai> PROPOSED: Merge PR 787
<TallTed> +1
<florian> +1, including TallTed's tweak
<cwilso> +1
<fantasai> RESOLVED: Merge PR 787