Re: Evergreen Formal Objection handling (ESFO)

On 3/19/2019 2:43 PM, Michael Champion 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.
>
> I agree with Chris and Dave, the editors and chairs can generally be trusted to do the right thing in such conditions.   The point of the Evergreen track is to provide a more optimal process for situations where up-front prototyping, data collection, and technical judgment  by the people most closely involved are working well.  The Rec Track process still exists for those situations where there is likely controversy, data is hard to gather or interpret, and formal consensus (or the authoritative resolution of objections) is needed to credibly consider something a standard.
>
> I suspect the best way to deal with Evergreen track failure conditions where there are controversies and objections by closely-involved experts is to move those specs move to the Rec Track, not to put a lot of consensus-checking bureaucracy into the Evergreen track.   (That's partly why I think the decision to move to the Evergreen track should be made after a spec is fairly mature and the WG can assess whether they can optimize for ease of progress or whether they need the Rec Track process to ensure that each step forward has broad consensus ... but I'm deferring pushing that argument until we have a better sense of how the Evergreen stage itself will work).

+1

My reading of Nigel's post is that he is in agreement as well about the 
different mechanisms to reach consensus on the REC track or Evergreen; 
but he is uncomfortable with the Evergreen "Recommendation" nomenclature.

>
> -----Original Message-----
> From: Nigel Megitt <nigel.megitt@bbc.co.uk>
> Date: Tuesday, March 19, 2019 at 10:47 AM
> To: David Singer <singer@apple.com>, Chris Wilson <cwilso@google.com>
> Cc: Florian Rivoal <florian@rivoal.net>, 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)
> Resent-From: <public-w3process@w3.org>
> Resent-Date: Tuesday, March 19, 2019 at 10:47 AM
>
>      Whether it¹s noise or a valuable check-point may well depend on the people
>      involved.
>      
>      Regardless, it is certainly possible to define a process in the WG that
>      establishes that the Decision Policy has been met for publishing a new
>      draft, and that empowers the Editor to publish when this process has been
>      successfully completed. For example, a group policy to merge pull requests
>      after a minimum of 2 weeks assuming there are no outstanding objections,
>      and to tie automatic publishing to merging pull requests to the master
>      branch.
>      
>      This is fine for drafts, but not fine for anything that purports to be a
>      W3C ³Recommendation² though, where a stronger approval should be required
>      in my view. If an ES is going to be updated like this, don¹t call it an
>      Evergreen Recommendation, call it something weaker sounding.
>      
>      
>      
>      On 19/03/2019, 17:38, "singer@apple.com on behalf of David Singer"
>      <singer@apple.com> wrote:
>      
>      >I¹m with Chris here.  We tell the editors it¹s their job to keep the WD
>      >alive and up to date, reflecting the consensus of the WG. If they
>      >occasionally mis-step (and they will) a member can complain and the chair
>      >and editor can sort it out. We don¹t need endless ³the editor requests
>      >permission to push the current editor¹s draft at X as the approved
>      >working draft of the working group² for every update. It¹s noise.
>      >
>      >> On Mar 19, 2019, at 10:33 , Chris Wilson <cwilso@google.com> wrote:
>      >>
>      >> I think you're conflating "consent" and "consensus" in these sentences,
>      >>and I think that's the key here.
>      >>
>      >> The Editor should be able to publish an update to the ES without
>      >>obtaining explicit consent.
>      >> The Editor should not publish updates that do not represent consensus.
>      >>(Obviously, they may accidentally violate this; however, most modern
>      >>editors carefully operate in this fashion (using PR review, etc.)
>      >> The Chair should, in my opinion, operate as an arbiter of that
>      >>consensus when further necessary; they should not need to explicitly
>      >>obtain consent for every publication of an ES, or we're pretty much
>      >>right back at Rec-track.
>      >>
>      >> On Tue, Mar 19, 2019 at 2:05 AM Florian Rivoal <florian@rivoal.net>
>      >>wrote:
>      >>
>      >>
>      >> > On Mar 19, 2019, at 0:49, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
>      >> >
>      >> >> Asking the Group to request a publication means that someone has to
>      >>approve the request, which we're trying to avoid.
>      >> >
>      >> > Why are you trying to avoid this?
>      >>
>      >> +1
>      >>
>      >> If the Editor can publish something without the consent of the group,
>      >>then the correct name for the document is "Editor's Draft", not "W3C
>      >>(Evergreen) Recommendation". If the editor needs the consent of the
>      >>group, then we can use our regular consensus approaches to declare
>      >>consensus. The Process already says enough about that, and further
>      >>refinements are for charters and chairs.
>      >>
>      >> If some group wants to be chaired and chartered to delegate to the
>      >>Editor the evaluation of consensus, with the chairs only serving as an
>      >>appeal / conflict-resolution path, they can already do that. In
>      >>practice, some groups (e.g. the CSSWG) already operate like that for
>      >>early stage drafts. However, most groups at most stages see value in
>      >>having else than the editor fill the role of facilitating and declaring
>      >>consensus, and do so using a variety of work modes. This is fine, and
>      >>there's no need to restrict what work modes are valid.
>      >>
>      >> ‹Florian
>      >
>      >David Singer
>      >Manager, Software Standards, Apple Inc.
>      >
>      
>      
>      
>      -----------------------------
>      https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.co.uk&amp;data=02%7C01%7Cmichael.champion%40microsoft.com%7Ceadf8d97d0ad43012a1f08d6ac92f439%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886144493960635&amp;sdata=dCxQGYweZuUMZTwzZfCgn2By%2B2nT46w65g8yFlf07gg%3D&amp;reserved=0
>      This e-mail (and any attachments) is confidential and
>      may contain personal views which are not the views of the BBC unless specifically stated.
>      If you have received it in
>      error, please delete it from your system.
>      Do not use, copy or disclose the
>      information in any way nor act in reliance on it and notify the sender
>      immediately.
>      Please note that the BBC monitors e-mails
>      sent or received.
>      Further communication will signify your consent to
>      this.
>      -----------------------------
>      
>      
>

Received on Tuesday, 19 March 2019 18:46:12 UTC