Re: Evergreen Formal Objection handling (ESFO)

On 3/20/2019 3:47 PM, Michael Champion wrote:
>
> >  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!
>
+1


> 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.
>
The current design has the following framework to deal with the 
situation.  Undoubtedly not perfect - but trying to give considerable 
autonomy to the Evergreen group, with some backstops.

1. Consensus of the WG is what goes into the ER.

2. Tooling marks those items that are less than 180 days old - so we all 
know which items have not had sufficient time for reasonable horizontal 
review.

3. Snapshots are another checkpoint - IPR commitments come in at 
snapshots so there is focus at that time frame.

4. We hope it rarely happens, but people can raise formal objections.  
We hope that WG, TAG, and community still work out a consensus - but 
something can go to the Director.

5. We encourage and expect that WGs will at some point go the final step 
to get the REC status - assuring unquestioned horizontal, AC, and 
Director review.

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