EverTeal

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 Wednesday, 28 August 2019 00:33:22 UTC