W3C home > Mailing lists > Public > public-w3process@w3.org > March 2019

Re: Evergreen Formal Objection handling (ESFO)

From: Michael Champion <Michael.Champion@microsoft.com>
Date: Thu, 21 Mar 2019 14:30:21 +0000
To: Florian Rivoal <florian@rivoal.net>
CC: Nigel Megitt <nigel.megitt@bbc.co.uk>, David Singer <singer@apple.com>, Chris Wilson <cwilso@google.com>, Philippe Le Hegaret <plh@w3.org>, Jeff Jaffe <jeff@w3.org>, "Siegman, Tzviya" <tsiegman@wiley.com>, W3C Process CG <public-w3process@w3.org>
Message-ID: <14BEE227-5811-4463-B0B6-6816B137C413@microsoft.com>
Thanks Florian, that's a good distinction between consensus building in a WG and getting approval to publish and I think we substantially agree.  I don't have a problem with WGs working on an ER have charter provisions that define a consensus mechanism for the WG that is more formal than "trust the editor."  As we discussed yesterday, the key point for Evergreen Recs is that to external audiences, there is a single, continuously updated source of truth about what the authoritative spec is.

-----Original Message-----
From: Florian Rivoal <florian@rivoal.net>
Date: Thursday, March 21, 2019 at 3:38 AM
To: Michael Champion <Michael.Champion@microsoft.com>
Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, David Singer <singer@apple.com>, Chris Wilson <cwilso@google.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)

    > On Mar 20, 2019, at 3:43, Michael Champion <Michael.Champion@microsoft.com> wrote:
    > [...] not to put a lot of consensus-checking bureaucracy into the Evergreen track.
    I think there's a misunderstanding here. I am absolutely not asking for more consensus-checking bureaucracy on the Evergreen track. Pretty much the opposite, since I am asking for fewer rules.
    Roughly speaking, the REC track boils to
    1) Make a spec draft, assessing consensus about it's content in anyway you want
    2) Decide to publish it, assessing consensus to do that in anyway you want
    3) Generate documentation showing that a bunch of criteria are fulfilled (the precise criteria you need to fulfil depend on the maturity level)
    4) Convince the team that the criteria have been fulfilled
    5) For some levels of maturity, get the AC to vote
    6) If there are formal Objection, wait for the Director to sort it out
    7) Wait for the Team to publish your Document
    ... Rinse and repeat, with different criteria for step 3 and 4 as you reach different maturity levels
    The Process does not require any kind of consensus checking bureaucracy for steps 1 and 2. Some charters do. Some chairs do. The Process does not. It requires that consensus be found and that decisions be made, and it is entirely up to Working Groups and their chairs to do that anyway they want (unless a charter ties their hands).
    Under the current process, it is perfectly fine for a charter and/or a chair to say that the way the establish consensus and take decisions is by trusting the editor do everything on their own. Publication aside (since that's step 3 and later), if a WG wants to empower their editors in the same way as the whatwg does, it is already possible. 
    I therefore propose that nothing needs to change about step 1 and 2 in the Process, and not restriction need to be added to the ways WG can establish consensus. Those who want to run procedural consensus or editor-led consensus can just do so under the existing Process.
    A number of groups may be interested in switching form the REC track to the Evergreen track based on not liking how the REC Track handles publication (step 3 and later). I don't see why we would deny them the possibility to do so unless they also change the way the Working Group operates internally.
    Evergreen should be about enabling a different approach to publication and to the broader W3C granting status to the output of a WG's work. Not about restricting WGs to a subset of the work-modes which are available today.

Received on Thursday, 21 March 2019 14:30:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:50 UTC