Re: EverTeal

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.
> 
>      -> 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 14:09:48 UTC