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

Re: EverTeal

From: Jeff Jaffe <jeff@w3.org>
Date: Fri, 30 Aug 2019 11:27:20 -0400
To: Philippe Le Hégaret <plh@w3.org>, fantasai <fantasai.lists@inkedblade.net>, W3C Process Community Group <public-w3process@w3.org>
Message-ID: <d45ca886-2aab-a9f1-ab9c-d5efeb00afd3@w3.org>
+1 to PLH's comments.  One nit in-line.

On 8/30/2019 10:09 AM, Philippe Le Hégaret wrote:
> Overall, I do have to admit that I like this proposal.
>
> Some thoughts below.
>
> On the pro side:
> - allow direct publications in /TR of the latest drafts agreed on by 
> the WGs
> - push patent commitments earlier than REC
> - It does introduce a new CR/PRD state but doesn't introduce 
> completely new ones
> - assumes we can change the patent policy (cf AC WBS)
> - preserves some of the current model:
>   * wide reviews costs is kept on the WGs to assert that a wide review 
> was done properly
>   * transition request checks for wide reviews and formal objections, 
> while not creating a Director bottleneck
>   * avoid requiring a new set of toolings, with continuous diffs or 
> annotations (but does not prevent those either).
>
> On the cons side:
> - Evergreen allows for PRDs sooner than CR, so it could still take a 
> few years before the patent commitments are settled
> - Everblue allows for re-publishing RECs with informative materials 
> that haven't been fully vetted yet, thus allowing more rapid iteration 
> of the RECs
>
> Philippe
>
> On 8/27/2019 8:32 PM, fantasai wrote:
>> About a month ago Ralph prompted the question of an EverTeal 
>> proposal, that would merge the Evergreen and Everblue proposals into 
>> one proposal. So I've been thinking on two questions:
>>
>>    - What would EverTeal look like?
>>    - What would I want the Process to be like if I wasn't starting
>>      from the constraints of what it is today?
>>
>> It occurred to me that both of these can have the same answer.
>>
>>
>> I have a few high-level wishes for the Process:
>>
>>   1. It should enable Working Groups to maintain their /TR specification
>>      as the authoritative copy of their spec *in practice*, which means
>>      that every edit that represents what the Working Group 
>> recommends to
>>      implementers is consistently and quickly published to /TR.

I'm a bit uncomfortable characterizing this as "WG recommends to 
implementers".  W3C's highest form of endorsement is called a W3C 
Recommendation, and I worry that the terminology (recommends to 
implementers) sounds a bit too close to W3C Recommendation.  W3C 
shouldn't provide that level of endorsement since there could still be 
open Formal Objections at this stage.

>>
>>      -> This means that recommendations to implementers do not sit in an
>>         Editor's Draft for months before being published, which causes
>>         the ED to become the authoritative copy in practice. (An ED 
>> should
>>         only exist as a temporary scratch space for working out, 
>> reviewing,
>>         and approving final edits. W3C should be hosting referenced 
>> specs.)
>>
>>      -> This means that recommendations to implementers do not sit in
>>         Pull Requests for months before being published [e.g. because 
>> they
>>         are waiting to be implemented before being finalized], which 
>> results
>>         in the authoritative copy being a pile of tentative PRs, instead
>>         of a single document where the feature's definition is 
>> explicitly
>>         shared knowledge available and obvious to all readers.
>>
>>   2. It should provide some structure, the way transition request 
>> currently
>>      do, that push a Working Group to review its own work, and that 
>> can be
>>      used by staff to catch where such work is not happening well: 
>> whether
>>      because the Working Group is new and inexperienced; or the editor,
>>      however capable and well-intentioned, let things fall through 
>> the cracks;
>>      or some other reason. (I have this opinion because of my many 
>> years of
>>      experience: the transition checks almost always result in me 
>> finding
>>      things that I missed.)
>>
>>      -> This includes checking that issues are being “formally 
>> addressed”,
>>         that comments are not summarily dismissed or continuously 
>> ignored.
>>
>>      -> This includes checking that coordination with horizontal 
>> review is
>>         happening productively.
>>
>>      -> This includes ensuring that the community (including people 
>> outside
>>         the Working Group itself) have been given a meaningful 
>> opportunity
>>         to review and provide feedback.
>>
>>   3. It would be extra nice if we could satisfy #1 while also having a
>>      higher-level view of progress: a periodic publication that batches
>>      changes into coherent sets that can be synced with a call for wider
>>      review and publicity.
>>
>>
>> Current status:
>>
>> Currently, each CR publication is treated as a transition, handling the
>> requirements for #2 as well as invoking a Call for Exclusions. The 
>> work here creates significant friction to updates, making it more 
>> appropriate to batch edits into less-frequent updates. (These types 
>> of checks are also more effective if done periodically rather than 
>> continuously.) Additionally, there's significant pressure on the 
>> legal side to batch their patent review work. So while we can 
>> streamline simpler CR transitions as Everblue tries to do, the 
>> combination of these factors (particularly the legal review) means 
>> throttling CR updates at roughly twice per year. Which doesn't 
>> satisfy #1...
>>
>> On the flip side, Evergreen Recommendations try to optimize #1 at the 
>> expense of #2. A model without checkpoints might work for senior spec 
>> engineers who understand and embrace their mandate to collect 
>> feedback and process issues, and know how to do it well through their 
>> own process. But W3C invites participation from communities who are 
>> less expert: an important part of what we do as an organization is 
>> supporting those communities through the involvement of more 
>> experienced staff, community members, and horizontal review members. 
>> The Process *should* be designed to leverage these resources and 
>> provide some guide rails. Also, we already have feedback from our 
>> horizontal review groups that they would find the Evergreen model 
>> harder to work with, in particular because they are all overloaded: 
>> it's better to put the burden on the Working Group to seek horizontal 
>> review rather than on the Horizontal Review Group to track every 
>> Working Group.
>>
>>
>> Proposal:
>>
>> Decouple CR publications from CR transitions by adopting the 
>> Evergreen model of continuous publications + snapshots. Specifically,
>>
>>    A. After the first CR publication (which is a Patent Review Draft and
>>       also invokes the traditional transition process), the Working 
>> Group
>>       can update the CR essentially at will, similar to ER.
>>
>>    B. Periodically, the WG issues a CR that is also a Patent Review 
>> Draft,
>>       similar to an ER snapshot. Like the initial CR (and unlike an ER
>>       snapshot), this publication needs to go through the transition 
>> process
>>       [possibly streamlined via Everblue adjustments], to ensure that 
>> the
>>       changes have received wide review, etc.
>>
>>    - Substantive changes since the last PRD should be continuously 
>> documented.
>>
>>    - PRD should be issued every 6-12 months if there have been 
>> substantive
>>      changes, and must be issued at least every 24 months after such 
>> changes.
>>
>> Benefits of this proposal:
>>
>>    - Solves the patent-review throttling problem for CRs in Everblue by
>>      disconnecting CR updates from patent review drafts.
>>
>>    - Addresses the horizontal review concerns with Evergreen by 
>> incorporating
>>      periodic checkpoints in connection with Patent Review Draft 
>> publications.
>>
>>    - Allows WGs to make their latest CR work available on /TR 
>> continuously.
>>
>>    - Does not rely on tooling or data that we do not have, other than 
>> a slight
>>      update to the spec templates.
>>
>>    - Resolves the relationship of Evergreen and Recommendation by 
>> merging
>>      onto a single track, eliminating concerns about the potential chaos
>>      of having two distinct Process tracks and providing a clear path 
>> to REC.
>>
>>    - Bonus: There are two tracks to walk through history: a 
>> high-level chain
>>      of Patent Review Drafts, and a low-level chain of every update. 
>> This can
>>      help reviewers and anyone trying to understand the evolution of 
>> the spec.
>>
>> References:
>>    Everblue https://www.w3.org/wiki/Maintainable_Standards
>>    Evergreen https://www.w3.org/wiki/Evergreen_Standards
>>
>> ~fantasai
>>
>>
>
Received on Friday, 30 August 2019 15:27:22 UTC

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