Clarify expectations about FO mitigations

[frivoal]

Here are some suggested improvements to the handling of mitigations of overturned decisions, based on discussions of #645 during the process CG call of October 13th.

---

Preview | Diff

[nigelmegitt]

Why is this a MAY for mature publications but a MUST for general transition requirements?

[frivoal]

It is "may" for updating a publication while staying at the same status, like CR->CR, because you may be in the process of dealing with issues. If you've got a pile of 30 issues, and you've fixed 15 of them, you have 15 left and they're still problems, but you've made progress, so republishing is an improvement. So, if you're ignoring FOs, you should be denied. If you're working through a pile of things, and you're not done with all of them yet, then it's fine.

For a transition to a more mature stage, you're actually supposed to have cleared the deck, so it's a "must" in that case.

[nigelmegitt]

Right, that makes sense (with one exception), thanks @frivoal - unfortunately the heading "6.3.4. Updating Mature Publications on the Recommendation Track" is suggestive of specifications at the higher end of maturity, rather than all stages. It could be a separate ticket, but renaming the heading would avoid this. E.g. "Updating Recommendation Track Publications without advancement".

The exception is Rec -> Rec transition, where I'd expect something like the streamlined requirements (which talk about issues, of which I think FOs are a subset) to apply even for team verification.

[frivoal]

Ah, right, I see. This is tricky, because the criteria for this doesn't apply to WD->WD transition. "Updating Recommendation Track Publications without advancement" as you suggested implies it would apply to all updates, not just certain ones as clarified in the opening paragraph. I suspect renaming could be useful for the reason you highlighted, but I don't think we've found the right name just yet.

[nigelmegitt]

Oh, I see that I was even more confused than I first realised when looking at this text. The text in §6.3.4 says "Certain requests" and does not define which ones, and then defines the term "Update requests", which is then referenced from elsewhere, which is where these are brought in normatively.

Maybe this subsection should be called "Requirements for Update Requests" and there could be a note that says that the option to make Update Requests is defined by reference from the relevant sections. Right now update request requirements need to be met for:

• CRS -> CRS
• Rec -> Rec

And they are called out as not being needed for CRD -> CRD and Registry Table updates.

Given that, we could state, even in a note, within §6.3.4, that those "certain categories" are exactly the two I listed above. I think it would help avoid confusion for other readers.

Could it be helpful to define a term for the special nature of CRS and Rec as being normative documents for which we expect/permit there to be normative references from other documents?

(sidenote: I still don't think normative references to CR are a good idea, but the decision to permit them is now ancient history)

[fantasai]

@nigelmegitt Can you file your comments here as a separate issue? :) I think your suggestions to clarify this make sense, but they're about clarifying pre-existing text.

[css-meeting-bot]

The Revising W3C Process CG just discussed Clarify expectations about FO mitigations.

The full IRC log of that discussion

<fantasai> Subtopic: Clarify expectations about FO mitigations
<fantasai> github: https://github.com//pull/659

[css-meeting-bot]

The Revising W3C Process CG just discussed Clarify expectations about FO mitigations, and agreed to the following:

• RESOLVED: Merge 659

The full IRC log of that discussion

<fantasai> subtopic: Clarify expectations about FO mitigations
<fantasai> github: https://github.com//pull/659
<fantasai> florian: Last time we did accept PR as part of DF about FO mitigations
<fantasai> ... we were happy with the substance of it, but during discussion noted some editorial improvements
<fantasai> ... I tried to make them
<fantasai> ... for the ppl who reviewed this, have not found problems with this PR
<fantasai> ... but while reviewing this, it made Nigel notice that something else wasn't clear
<fantasai> ... so might have some text from last year that needs improvement
<fantasai> ... so I think that needs follow-up, but this PR does the job of clarifying things correctly
<fantasai> plh: anyone need more time?
<fantasai> <fantasai> +1 to merging
<fantasai> RESOLVED: Merge 659
<fantasai> ACTION: florian to open up separate issue for Nigel's comments