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

Re: Evergreen Formal Objection handling (ESFO)

From: Jeff Jaffe <jeff@w3.org>
Date: Thu, 14 Mar 2019 14:45:34 -0400
To: Chris Wilson <cwilso@google.com>
Cc: David Singer <singer@apple.com>, W3C Process CG <public-w3process@w3.org>, Philippe Le Hegaret <plh@w3.org>
Message-ID: <bf143d49-e133-1b80-a0a1-4bec9bef292c@w3.org>
Thanks, Chris.  This helps a lot.

So modeling a FO objection policy after this (which is consistent with 
the current FO policy), I suppose we only need to say that the Director 
can override an Editor's decision.  Correct?

Jeff

On 3/14/2019 2:11 PM, Chris Wilson wrote:
> In short, the WHATWG Workstream Policy 
> (https://whatwg.org/workstream-policy) says "Editors are responsible 
> for the technical content of their Workstreams", and the "Steering 
> Group appoints and may remove the Editor for each Workstream".
>
> The core of responsibilities is in 
> https://whatwg.org/workstream-policy#relationships-with-other-groups:
>
>  1. Editors must respond to substantive issues raised by Workstream
>     Participants in their Workstreams. Editors have discretion to
>     resolve issues based on available information.
>  2. If a Workstream Participant is not satisfied with an issue
>     resolution, they may request that the Editor revisit the issue. If
>     not satisfied with an Editor's final response, Workstream
>     Participants may appeal to the Steering Group.
>  3. Editors may solicit input from Workstream Participants, and may
>     consider and respond to comments, suggestions, and objections from
>     Contributors and the public.
>
> The conflict resolution policy is just below it, in 
> https://whatwg.org/workstream-policy#decision-making:
>
>  1. Editors may commit changes to their Living Standards without
>     further review, provided they are adhering to the requirements above.
>  2. The Steering Group may override an Editor's decision, or remove an
>     Editor.
>
> So in short: Editors are responsible for responding to all issues.  If 
> a participant is unhappy with the Editor's (repeated) response to an 
> issue, they should appeal to the Steering Group, which may override or 
> remove the Editor.  (This would, of course, be somewhat catastrophic, 
> so in practice, working with consensus approval is highly encouraged, 
> and is the norm.)
>
> I would point out that the Working Mode of the WHATWG also has a high 
> bar for what goes IN to a Living Standard, as laid out in 
> https://whatwg.org/working-mode#changes:
>
>     Each normative change made to the standard needs to meet the 
> following criteria:
>
>  1. It must have support from implementers.
>  2. It should have corresponding test changes, either in the form of
>     new tests or modifications to existing tests.
>  3. Implementations bugs must be filed for each user agent that fails
>     tests. (This is each user agent that doesn’t match the proposed
>     changes. If the test changes are not adequate to reveal that, but
>     it’s known through other means, the tests should be improved first.)
>  4. It should have been reviewed by one or more members of the community.
>  5. Optional or implementation-defined behavior must be very well
>     motivated.
>
> Another thing of note - Editors MAY (but are not required to) tag text 
> as "Object Pending" or "Under Discussion", as stated in 
> https://whatwg.org/workstream-policy#optional-tags.
>
> On Wed, Mar 13, 2019 at 4:01 PM Jeff Jaffe <jeff@w3.org 
> <mailto:jeff@w3.org>> wrote:
>
>
>     On 3/13/2019 6:19 PM, Chris Wilson wrote:
>>     I note that this is, in fact, a quite complex bit of Process, and
>>     wonder (as Mike has introduced) if we would be better served with
>>     a process more akin to the Living Standard process we used in the
>>     WHATWG; putting FOs into the document itself, although I
>>     understand the rationale, seems like an attack vector for those
>>     who disagree.
>
>     I'm interested in learning more about "a process more akin to the
>     LS process".  I don't know much about the WHATWG process.  Can you
>     suggest some process-text which would characterize what you mean?
>
>
>>
>>     I'd again suggest that the Chair should be more responsible for
>>     maintaining consensus.  (And yes, I have an action item to
>>     propose some text.  Was this moving to a repo somewhere, or
>>     should I just do this in email?)
>>
>>     On Wed, Mar 13, 2019 at 12:51 PM Jeff Jaffe <jeff@w3.org
>>     <mailto:jeff@w3.org>> wrote:
>>
>>         Thanks, David.  I generally agree with your direction.  Many
>>         comments on the minutiae.  (And shouldn't we have this
>>         discussion on github?)
>>
>>         On 3/13/2019 2:38 PM, David Singer wrote:
>>>         Hi
>>>
>>>         here’s my suggestion. Replace this
>>>
>>>         	• must ensure Director review of all pending formal objections before 24 months have elapsed.
>>>         ISSUE-FO: what happens if the Group refuses to accept the Director's resolution? Some ideas:
>>>         		• The Working Group ceases its work
>>>         		• The Working Group is no longer allowed to publish an ERS
>>>         		• The document header indicates that the Director disagrees with some parts of the document
>>>
>>>         with
>>>
>>>         If a Formal Objection is raised against an Evergreen Standard:
>>
>>         We need a time interval that guarantees that a FO will be
>>         taken up and resolved within some bounded amount of time. 
>>         The current text says 24 months, which may be too long.  What
>>         do people think?
>>
>>>         * Until it is resolved, all copies (including the working group’s working draft, and the document linked as the current ES)
>>         We don't have WDs for Evergreen.  So it suffices to say that
>>         the ER MUST document the FO in the header.
>>>           MUST document the existence of the unresolved FO in the document header, and SHOULD document it also in the body of the text near the subject material;
>>         Not clear to me why this SHOULD isn't a MUST.
>>>         * After resolution, the current ES must either reflect the decision (the Director’s decision, or the agreement reached with the consensus of the WG and objector under which they withdraw their FO), or cease to be published; if the working draft or other documents of the WG do not reflect the decision, the FO marking MUST be retained.
>>
>>         Instead of having all of the notes, it might be cleaner to have:
>>
>>         Resolution:
>>
>>           * If the FO is rejected, the FO documentation is removed
>>             from the header and the document
>>           * If the FO is accepted, the document MUST reflect the
>>             Director's decision if it is to continue as an ER.  If
>>             the Working Group does not agree, then options include:
>>               o Removing the ER designation and publishing as a Note
>>               o Reverting to an earlier version of the ER which does
>>                 not have the objection
>>               o Returning to a Preliminary Draft stage until a
>>                 consensus can be found for the objection
>>           * If the Director, objector, and WG develop a different
>>             consensus approach, then that approach is put into the
>>             document and the FO documentation is removed
>>
>>>         Note: if the FO is rejected, the markings are removed. If the FO is upheld, and the document can be easily adjusted (e.g. removal of an ‘atomic' feature), this should be straightforward. In complex cases, the ES may need to revert to a state to which the FO does not apply, and if there is no such state, return to provisional status with no ES publication.
>>>
>>>         Note: resolution can include reaching an agreement with the objector and the objector withdrawing their FO in favor of this resolution.
>>>
>>>         Note: the Director’s decision can, of course, be appealed.
>>>
>>>         Note: there are too many Notes here.
>>>
>>>
>>>
>>>         David Singer
>>>         Manager, Software Standards, Apple Inc.
>>>
>>>
Received on Thursday, 14 March 2019 18:45:37 UTC

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