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

Re: Evergreen Formal Objection handling (ESFO)

From: David Singer <singer@apple.com>
Date: Thu, 21 Mar 2019 17:11:33 +0000
Cc: Chris Wilson <cwilso@google.com>, Florian Rivoal <florian@rivoal.net>, 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: <0F544239-80C9-4BF7-B85C-34A9F114BAC4@apple.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>


> On Mar 19, 2019, at 17:46 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> 
> Whether it¹s noise or a valuable check-point may well depend on the people
> involved.

I’m sorry, I should have said it may be both WG-dependent, and where in the process the WG is.  For example, when trying to ‘land’ a perfect CR, the WG may indeed want to review every change prior to commit.

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

I’m not sure I agree…

> 
> 
> 
> 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.
>> 
> 
> 
> 
> -----------------------------
> http://www.bbc.co.uk
> 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.
> -----------------------------

David Singer
Manager, Software Standards, Apple Inc.
Received on Thursday, 21 March 2019 17:12:14 UTC

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