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
Addressing formal objections before requesting advancement #737
Comments
I think this is just a restatement of the requirement in §6.3.3:
If my understanding is correct, it should remain a note so that we do not duplicate normative requirements, but the note could possibly be reworded to reference this specific requirement more clearly, if that would help. |
A minor point, but "against matter in a technical report" could be improved to read "against the content of a technical report". |
First, does the note need to be in this section if its content is already in §6.3.3? If it does need to be here, it would help to reword it in order to say what kind of "addressing" the objections need. The current wording implies to me that the objections need to be addressed using https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-04#addressing-fo instead of the simpler process at https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-04#formally-addressed. Perhaps:
|
That's probably a tidier way of saying what's in the note now @jyasskin. |
"formally addressed" and "fully addressed" are actually different things, so I think the rephrasing above would inadvertently make a normative change. Looking into a clarification may be worth doing, but this isn't it. |
This remains a Note, and my suggestion removes the normative wording, so it can't make a normative change. Maybe it misstates the existing normative requirement that's somewhere else? But I used the same one of "formally" or "fully" as in the requirement that Nigel found, so which existing requirement are you thinking of? |
It doesn't introduce the requirement, it references a requirement already normatively established elsewhere. But editorially, it did look wrong. #803 will address this (and a few similar problems elsewhere in the document) |
The proposed replacement reads:
@jyasskin I think this change would address this issue, let us know if that works for you? |
@jyasskin If there are open FOs against the document, then, yes the Council needs to run before a FPWD/CR/PR/REC can be published. The initial publication of a WD/CR/PR/REC should have no unresolved FOs. |
Based on the above, I think this can be closed. @jyasskin, can you confirm? |
Yep, looks resolved to me. |
resolved by #803 |
https://www.w3.org/Consortium/Process/Drafts/snapshots/2023-04#registering-objections includes:
First, a "Note" shouldn't introduce a requirement.
Second, this requirement seems to reverse the usual ordering of things. My understanding is that usually a working group calls for consensus to request advancement, some members might object, they get overruled by the group as a whole, which requests advancement, and then those members formally object to the Team, which follows the rest of the Process to handle the objection. The requirement in this note appears to say that if a member registers their objection to the Team before the end of the call for consensus, the request for advancement has to wait for the entire FO Council process to finish.
This text was introduced by #642, but I don't see discussion about it in that PR.
The text was updated successfully, but these errors were encountered: