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> wrote:

>
>
> 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
>