W3C home > Mailing lists > Public > public-w3process@w3.org > March 2019

Re: Grounds for Formal Objections

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 20 Mar 2019 12:11:38 +0900
Message-Id: <E70BE13E-F121-42B0-A813-6D607CA55AA0@rivoal.net>
Cc: public-w3process@w3.org
To: fantasai <fantasai.lists@inkedblade.net>

> On Mar 20, 2019, at 0:12, Jeff Jaffe <jeff@w3.org> wrote:
> Absence of formal objections is an indication that an organization is successful in deciding by consensus.  It might be an indication that the process does not require FOs.  Or it could equally indicate that the existence of the escape valve (the FO) drives people towards consensus.

Good point.

> On Mar 20, 2019, at 11:15, fantasai <fantasai.lists@inkedblade.net> wrote:
> [...]
> There was no process violation. Would you disregard the i18n's FO in
> such a case just because there was no process violation?
> Formal objections for process violations are only necessary if the chair is not
> doing his/her job correctly. In a well-chaired group, they will only happen on
> technical grounds. If you don't allow them to happen on technical grounds then
> there is no technical escalation path: each WG is the ultimate authority on its
> specs, and there is no means of appeal.
> [...]
>  Since you're not proposing to do that, the TAG has no formal authority
> over technical decisions, and their feedback can be rejected by the WG after
> careful consideration. There's no process violation. There's still a formal
> objection. Now what?

The approach that would be followed there is that when the feedback from the TAG or the i18n group is rejected, that has to be shown in a disposition of comments.

If it is not there, or if it's there but looking at it shows that it was brushed off without meaningful consideration, there's ground for a a process based FO (based on section 3.3.3 of the Process being violated).

The interesting case is if there is a DoC and the feedback has been properly addressed, but rejected. First, even without anything in the Process, the Team can attempt to mediate a compromise. But let's say that fails.

At least in the case of the REC track, the way that would be caught is when there's an AC Review for moving to a new maturity level. The DoC would show that the WG disagreed with the horizontal review groups or the TAG, so the AC could make a judgement call as to whether that was appropriate, or if the spec should be rejected on these grounds and sent back for further work. To facilitate that, we could (either in practice, or via the Process if needed) make sure that rejected feedback from horizontal review groups or the TAG must be highlighted in the Call for Review, and that the group whose comment has been rejected should document their recommendation to the AC (e.g. "unfortunate, but the spec as a whole is still useful, so approving it is fine", or "unless this is addressed, the spec is harmful to the web, so it should be rejected") with its rationale. Then the AC judge on these grounds.

Having said all that, I might have just convinced myself away from this proposal, for two reasons. I don't think either are necessarily complete show-stoppers, but they now make me lean the other way:

* The above does imply that even if we disallowed non procedural FOs to WG decisions, during AC Reviews, FO on non procedural grounds need to be possible as well, otherwise the AC cannot block. So we need to have a way to cope with those. As long as we do, we might as well allow direct non procedural FOs to WG decisions, without the indirection of an AC Review in between. Maybe the indirection is useful, as making the process more convoluted might discourage frivolous FOs. Maybe not.

* This approach also presumes that the AC is an active and engaged body. By and large, this is not the case today. Maybe that is something we can/should fix, but if not (and I am skeptical that we can), we should design the Process around that fact, and then having an FO process that can directly address non procedural issues is probably a better way. If that's something we can/should fix, maybe the above can work.

Received on Wednesday, 20 March 2019 03:12:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:50 UTC