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.

Sign up for GitHub

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

Jump to bottom

Clarify expectations about FO mitigations #659

Merged
merged 2 commits into from
Oct 27, 2022
Merged

Clarify expectations about FO mitigations #659

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
10e9b35
Clarify expectations about FO mitigations
frivoal Oct 14, 2022
04f2fce
Shorten note
frivoal Oct 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 9 additions & 2 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2441,7 +2441,12 @@ Council Deliberations</h5>
(e.g., if the objection concerns material already in a published document)
the Council <em class=rfc2119>should</em> suggest how these consequences might be mitigated.
The [=Team=] is responsible for making sure that adequate mitigations are enacted in a timely fashion;
and the [=Formal Objection=] is not considered fully addressed until then.
and the [=Formal Objection=] is not considered <dfn>fully addressed</dfn> until then.

Note: This does not create new powers for the [=Team=],
such as the ability to “unpublish” documents.
The [=Team=]'s role is to ensure the responsible parties enact adequate mitigations,
by whatever means they already have at their disposal.

The Council <em class=rfc2119>may</em> form sub-groups for deliberation,
who may return with a recommendation,
Expand Down Expand Up @@ -3364,7 +3369,8 @@ Advancement on the Recommendation Track</h4>
<em class="rfc2119">must </em> obtain [=Team=] verification.
[=Team=] verification (a [=Team decision=])
<em class=rfc2119>must</em> be withheld if any Process requirements are not met
or if there remain any unresolved Formal Objections,
or if there remain any unresolved Formal Objections
(including any [=sustained=] by the [=Council=] but not yet [=fully addressed=]),
or if the document does not adequately reflect all relevant decisions of the [=W3C Council=] (or its delegates).
If the [=Team=] rejects a [=Transition Request=]
it <em class=rfc2119>must</em> indicate its rationale
Expand Down Expand Up @@ -3437,6 +3443,7 @@ Updating Mature Publications on the Recommendation Track</h4>
[=Team=] verification (a [=Team decision=]),
<em>should</em> be withheld if any Process requirements are not met,
and <em class=rfc2119>may</em> be withheld in consideration of unresolved Formal Objections
(including any [=sustained=] by the [=Council=] but not yet [=fully addressed=])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

or if the document does not adequately reflect all relevant decisions of the [=W3C Council=] (or its delegates).
If the [=Team=] rejects an [=Update Request=],
it must indicate its rationale to the [=Working Group=].
Expand Down