Re: EverTeal

Hi Process CG,

Fantasai and I made a first pass at at incorporating everteal into the Everblue branch of the Process document.

* Preview of the result:
  https://w3c.github.io/w3process/everblue/

* Diff against current master branch:
  https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fw3process%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fw3process%2Feverblue

Feedback very much welcome, especially in the form of specific issues raised in https://github.com/w3c/w3process/issues with label "Everblue/teal".

—Florian
PS: As with the rest of Everblue, this is currently written assuming an updated patent policy, and references to the patent policy reflect that. We're very well aware that there's much work left to do in this area, but nonetheless feel that the rest is sufficiently complete to solicit detailed feedback.

> On Aug 28, 2019, at 9:32, fantasai <fantasai.lists@inkedblade.net> 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 Thursday, 24 October 2019 06:45:13 UTC