Re: Evergreen Formal Objection handling (ESFO)

> On Mar 20, 2019, at 3:43, Michael Champion <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