Council decision side effects

[mnot]

When sustaining an objection, it should recommend a way forward. If the overturned decision has already had consequences (e.g., if the objection concerns material already in a published document) the Council should 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.

This attaches new and relatively unconstrainted powers to the Council -- what is the status of their 'recommendations' and 'mitigations'? Are the required to be followed? If they have unanticiapted side effects on other matters that have consensus, can they be appealed?

The safest thing to do would be to remove this text and only empower the Council to give a thumbs up/down. Failing that, stating that the recommentations are to the WG are suggestions for further consideration, without formal standing would help. Any mitigations that require Team action should be limited to those activities which the Team has authority to perform.

[frivoal]

This attaches new and relatively unconstrainted powers to the Council -- what is the status of their 'recommendations' and 'mitigations'?

No new power is attached. The council can suggest and recommend, not mandate, demand, enforce, or anything of that sort.

Are the required to be followed?

No.

If a formal objection has been sustained, there's two cases, either:

• it was a formal objection to a proposed decision, in which case the decision simply doesn't happen. Beyond that, the Council's input, if any, is non binding. This is not a "you ought to do X", but rather a “We think there might be a way out of this problem if you consider X. Whatever gets to consensus is fine, but if you're struggling (as evidenced by the fact that a formal objection not only was raised but also sustained), maybe give this some thoughts, because we think it might help.”

• it was a formal objection to a decision that has already had consequences. There too, the council's specific input on what should be done about it is still non binding. What is required though is that something is done to undo or counteract or mitigate the consequences of that decision that has been voided, and the Team is in charge of tracking that it isn't forgotten.

For instance, if someone formally objects to a particular feature having been added to a spec, and the Council sustains that objection, neither the Council nor the Team has the ability to just change the document outright: WG documents are under WG control, and the Patent Policy might not function properly if things were changed in a WG's draft by someone else. As a mitigation, the Council might recommend deleting the offending feature, or maybe using XML instead of CSV as the underlying data format for that feature. The Working Group would then consider doing either of those, but may find that instead, changing the feature to use JSON is what gets group consensus, so they're happy to do that instead. The Team's role here would be not to enforce any particular outcome, but to ensure that something is done so that the offending text does not indefinitely remain as is, and to stand in the way of advancement otherwise.

If they have unanticiapted side effects on other matters that have consensus, can they be appealed?

You can AC Appeal the sustain vs overrule decision. Beyond that, there's no need to appeal anything, because all the rest is informative, so you can just ignore it without appealing.

The safest thing to do would be to remove this text and only empower the Council to give a thumbs up/down.

That is the only power they do have. The rest is informative guidance.

Failing that, stating that the recommendations are to the WG are suggestions for further consideration, without formal standing would help.

I think that's what we do? The operative verb in the the relevant process sentence is suggest: “Council should suggest how these consequences might be mitigated”.

Any mitigations that require Team action should be limited to those activities which the Team has authority to perform.

I believe that the Note in the Process right after the paragraph you quoted already speaks to that effect:

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.

[mnot]

It may be this text that's making me a bit uncomfortable:

The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion

... because it seems to make the Team responsible for implementing the suggestions/recommendations, rather than having the community (WG, whatever) reflect upon them and take them as input to further action.

[plehegar]

The council can only sustain or overrule an objection and everything else would be recommendations. The Team cannot enforce an outcome from a Council if it's only a recommendation however since those are only SHOULD. A recent parallel is the decision around DiD 1.0, where the Director included a recommendation for a future charter. It was clarified to the Working Group that the Director's recommendation was not a requirement.

[frivoal]

The Team is responsible for making sure that adequate mitigations are enacted

it seems to make the Team responsible for implementing the suggestions/recommendations

Not "the suggestions". "adequate mitigations".

We did not want to allow for a situation where someone objects to text having been added to a spec, then the council sustains that objection, and then nothing happens, and the text stays unchanged. Yes, the WG should fix it. What if they don't?

The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion.

[mnot]

We did not want to allow for a situation where someone objects to text having been added to a spec, then the council sustains that objection, and then nothing happens, and the text stays unchanged. Yes, the WG should fix it. What if they don't?

If the Council sustains an objection, the document doesn't progress; it goes back to the WG (or wherever) for further discussion. What should not happen is that the Council says "sustained, and here's what you should do..." and that gets reflected in the document without adequate community discussion -- including consensus on whatever the eventual solution is.

The current text leaves the impression that the Team is the only party acting upon a Council's advice; that's not the case.

Aside -- A council making "suggestions" could be read to imply that following them will satisfy the issue. That isn't the case, because any subsequent FO would be resolved by what is technically a different council.

[othermaciej]

It seems entirely reasonable to allow (perhaps even encourage) Councils to provide suggestions on possible ways to execute the actual binary decision. And the original quoted language seems pretty clear that these are merely suggestions, and appears intended that way. Perhaps to avoid any lingering ambiguity on whether "adequate mitigations" is equivalent to "suggest[ions for] how these consequences might be mitigated", perhaps this:

The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion

Could be lightly edited to this:

The Team is responsible for making sure that adequate mitigations, whether based on the council's suggestions or otherwise, are enacted in a timely fashion.

[mnot]

@othermaciej that proposal makes it worse. I'd suggest:

The Council's recommendations and suggestions are taken back to the body who made the decision which the Formal Objection was made against (e.g., Working Group, Advisory Committee, TAG, or AB) for further consideration and discussion.

[fantasai]

@mnot Your suggestion doesn't address the case of a group ignoring the need for mitigations, which is the entire purpose of that sentence about the Team. See #751 (comment)

[mnot]

If the group fails to address the underlying issue, surely there will be another FO when it attempts to execute a decision again?

[fantasai]

@mnot The objector shouldn't need to track the resolution of their FO (which might take months or years to be dealt with). We're putting this responsibility on the Team, because they're in a much better position to follow up (since it's literally their job to make sure the Process is executed properly).

[mnot]

I'm not so concerned with the effort to track your FO -- more in transparency in how the council ruling is applied.

So there seems to be an assumption that the flow is (for example):

graph TB;
WG(Working Group);
decision([Decision]);
obj(Objector);
fo([Formal Objection]);
council(Council);
ruling([Ruling]);
team(Team);
WG -- makes --> decision;
obj -- makes --> fo -- to --> decision;
decision -- goes to --> council;
council -- makes --> ruling -- implemented by --> team;

What I'd like to see more explicitly is the group who originally made the decision reconsidering it in light of the council ruling, e.g.:

graph TB;
WG(Working Group);
decision([Decision]);
obj(Objector);
fo([Formal Objection]);
council(Council);
ruling([Ruling]);
team(Team);
WG -- makes --> decision;
obj -- makes --> fo -- to --> decision;
decision -- goes to --> council;
council -- makes --> ruling;
ruling -- taken under advisement by --> WG;
team -- observes and manages WG handling of --> ruling;

[nigelmegitt]

@mnot if the Ruling is to uphold the Formal Objection and effectively rescind the Decision, the WG can't only take it under advisement: that suggests that the WG can say "that's interesting, we're going to keep going with our Decision regardless", or alternatively, just make the same Decision again, repeatedly.

The consequence of an FO upheld by the Council is that the Decision is no longer a Decision. The choices are:

1. Someone can appeal the Council ruling on the FO, or
2. the WG can seek consensus for a modified Proposal, or
3. the WG can abandon the Proposal altogether.

[mnot]

@nigelmegitt agreed, that was a poor choice of words on my part. What I'm trying to say is that the group (or whoever decided it) needs to recondiser and form a new opinion. However, the wording in the current process is to the effect that it goes to the Team and (magic happens).

[chrisn]

What I'm trying to say is that the group (or whoever decided it) needs to recondiser and form a new opinion. However, the wording in the current process is to the effect that it goes to the Team and (magic happens).

I agree that's how the Process reads at the moment. Perhaps a rephrasing along the lines of "With oversight of the Team to ensure that adequate mitigations are enacted in a timely fashion, the group that made the original decision is responsible for ..." ?

[dwsinger]

well, notably, the original decision is rescinded and the team will not only ensure the mitigations (e.g. backing up on the Rec track) but will prevent any attempt to re-make the original decision (e.g. the WG asks to re-send the same document for ballot).

[mnot]

That may be implied and there may be a shared understanding of it, but it's not what's documented.

[dwsinger]

agreed, we might like to clarify that

[frivoal]

However, the wording in the current process is to the effect that it goes to the Team and (magic happens).

That is not the intent, and I don't really see how the phrasing would lead to that.

well, notably, the original decision is rescinded and the team will not only ensure the mitigations (e.g. backing up on the Rec track)

No? Let's look at what the process actually says:

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.

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 Note directly contradicts @dwsinger's claim. The team isn't getting new powers to remove some published thing from having been published. The working group is supposed to go fix their spec (if the objection was on the content of a spec), by whatever means they already have at their disposal, so group discussion and consensus building and taking resolutions and so on.

The Team's role is to make sure they do it. It the Working Group chair fails to take it up for instance, the Team should remind them. If they refuse to, the Team could remind them that Chair appointment is up to them. If that's not enough of a clue, and the chair still refuses to schedule it, the Team, using their existing powers, could indeed appoint a new chair who will deal with it.

If the chair is dealing with it, but the group just doesn't feel like changing anything, the team should remind them that they're supposed to. If they take a while to find a good solution, that's fine. If they just refuse to deal with it and try to publish updated version of the spec anyway, the team can block publication (see the second bullet in https://www.w3.org/Consortium/Process/Drafts/#transition-reqs). Eventually, the Team could invoke https://www.w3.org/Consortium/Process/Drafts/#rec-track-regression, or https://www.w3.org/Consortium/Process/Drafts/#abandon-draft.

But it's not "magic happens". It's "usual process happens, with the Team holding people to it".

Maybe it would work better if "the responsible parties" was moved from the note to the main sentence. But it is already there in the text. I can agree that editorial improvements can be welcome, but I cannot agree that the text gives the responsibility to the team to do themselves things they would normally not have the power to do, when the text explicitly says that's not the case.

Also, keep in mind, the text needs to be generic enough to apply to all FOs. Not all of which are about specs, nor about WG decisions.

What I'd like to see more explicitly is the group who originally made the decision reconsidering it in light of the council ruling
[Diagram]

Basically, that's what the current text already aims to do. Except:

• The original decision is not necessarily by a "group" (could be a chair, could be a team member…)
• I'd say that what the Team is supposed to do goes a little bit beyond "observe and manage". If the decision originator is dragging feet, it should go into "demand", and possibly use whichever tool the Process already gives them to make sure stuff happens. Ignoring it is not an option. But indeed, in no case is the Team supposed to take on process roles it doesn't have in the first place, such as writing specs, un-publishing things, make substantive changes to an active charter without AC review…

[fantasai]

@mnot I believe your issue here is invalid, as explained by @frivoal in #751 (comment) . If you don't believe this is the case, please explain why.

[mnot]

Characterising it as 'invalid' is odd - you have at least two people who are not unfamilar with the process reading something into it that you didn't intend, and Florian took many words to explain why not. Why would you not clarify the text here?

[fantasai]

@mnot Reading in between the lines of your comment, I interpret it as saying that you agree your issue is substantively invalid, but want editorial changes to make it more obvious. Is that a correct interpretation?

[frivoal]

From my point of view, this issue highlights that we could do a better job editorially, since it doesn't appear obvious to everyone. However, I have not seen any comment that points to any part of the Process actually being substantively different from what is being characterised as the desired behavior, and some comments about what the Process supposedly mean are actually in direct contradiction of text in the Process.

As I have explained in detail, the Process is substantially requiring exactly what you want it to require. It does so in generic terms because it has to apply to all sorts of situations; and while that may make it a bit hard to interpret concretely, that doesn't make it wrong. My explanation is indeed long, because I'm illustrating what that means in some specific scenarios. We could possibly write a whole guide article for it (and that might be an actual good idea), but that level of explanation won't belong in the Process itself.

We could possibly do something about it editorially to make it a little more obvious. However, whether it's worth holding the Process up for non-trivial† editorial changes requested at the last minute for something that has been under review for 6 months is another question (which is on the Director to answer).

† Non-trivial, as exemplified by the fact that every proposed rephrasing in this issue so far introduces substantive regressions.

If it were up to me (but it's not), I'd say the substantive claims in this issue are invalid, and I'd advise deferring on any editorial changes.

[mnot]

I don't think this is "invalid", but accept that it's editorial, and would be ok with it being deferred until the next process iteration.