Re: Evergreen Formal Objection handling (ESFO)

>  The whole point of ES is to have one source of truth, not "look here for the current REC, but over here if you want to track current work."

Great one-line summary!  It does take a high-functioning group to pull off a Living Standard / Evergreen Recommendation process, with a lot of trust between the Editor and group, and good alignment with the real-world implementers/site developers.  It is definitely not for those who find the current Rec Track process adding significant value.   But the Evergreen process won’t get used if it is not significantly easier to use than the Rec Track for cohesive communities that don’t need constant assurance that the single source of truth is actually true.

I’m frankly not sure how to handle situations where the cohesive WG’s one source of truth doesn’t align with the larger W3C community’s sense of what truth should look like, e.g. if the TAG has unresolved concerns or there are Privacy, Security, Accessibility, or Internationalization issues that aren’t accepted by the WG.  I’m tempted to say the nuclear option of de-chartering the WG is the way to handle such (hopefully rare) situations.  A less nuclear option would be to replace the chairs or editors … but that could be essentially the same as the nuclear option if the group takes their spec to another organization in protest.



From: Chris Wilson <cwilso@google.com>
Date: Wednesday, March 20, 2019 at 9:24 AM
To: Florian Rivoal <florian@rivoal.net>
Cc: Michael Champion <Michael.Champion@microsoft.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, David Singer <singer@apple.com>, Philippe Le Hegaret <plh@w3.org>, "jeff@w3.org" <jeff@w3.org>, "Siegman, Tzviya" <tsiegman@wiley.com>, W3C Process CG <public-w3process@w3.org>
Subject: Re: Evergreen Formal Objection handling (ESFO)

It sounds like you are already getting everything you need from the REC process, which is great. There's no requirement to move away from that process if it works for your group.

The problem is that there are situations where the process (transitioning to new maturity levels, but even just the group-resolution-to-publish requirement) *is* onerous.  I certainly agree that any group would want to be careful about any change they made to an ES - but that's the responsibility of the Editor.  I *don't* agree that every publication should require group resolution for ES - because that puts a consistent barrier and time lag between when the editor publishes what they believe is consensus, and when it shows up as the "current standard".  The whole point of ES is to have one source of truth, not "look here for the current REC, but over here if you want to track current work."

On Tue, Mar 19, 2019 at 8:30 PM Florian Rivoal <florian@rivoal.net<mailto:florian@rivoal.net>> wrote:



On Mar 20, 2019, at 3:43, Michael Champion <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com>> wrote:

I think the fundamental issue here is that the WG process with all sorts of mandatory steps to check consensus is most suitable for situations where the real-world isn't providing continuous feedback about whether an idea works or not.  It optimizes for the cases where there isn't technical agreement and empirical data, ensuring that a broad range of people buy into the judgment call the WG is making, since it is expensive to be wrong. The Living Standard / Evergreen alternative emerged because in many web platform cases there's a lot of experiments and empirical data being brought to the table before a spec is locked down, and all those calls for consensus, formal objections, appeals, etc. are either irrelevant bureaucracy or used mostly for political reasons to block something being considered a "standard."   It's not so expensive to be wrong if the editor can quickly fix problems that are noted in the real world.

Given that Working groups can already adopt this style of decision making (for Working Drafts at least), thanks to the Process's general flexibility about how consensus is ascertained and how WG decisions are made, why not leave the part about consensus and decision making unchanged from the current process, and specialize it on a group by group or spec by spec basis by writing things into charter, or even at a finer grained level (for instance to take maturity into account) by leaving it at the discretion of the WG chair?

Evergreen doesn't always mean changing fast. A stable spec should change occasionally to reflect reality, but that doesn't mean we necessarily need to push out 3 new version onto TR every week. Let's say the CSS-WG wants to maintain CSS2.1 under the EverGreen process to reduce some of the publication overhead. For that particular group and that particular spec, I'd expect that we'd still be very careful about every change we make, and that we'd want a group resolution before pushing out an update.

So, I am not saying that ER specs should never work according to the proposed workflow, just that workflow is already allowed by the Process (other than specific clauses about transitioning to new maturity levels, which would not apply here). Groups that want to adopt it could, and we don't need to mandate it, so that groups that want to be more deliberate could as well.

Enforcing the more casual style of ER at the Process level would rule out the middle ground between full-casual ER and full-formal REC. I don't see the benefit.

—Florian