Re: EverTeal

I think EverTeal is a strong proposition. It has the advantages of both 
EverGreen and EverBlue, but also eliminates many of their disadvantages.

Although it is possible to integrate horizontal specialisms into a rapid 
iteration methodology, it requires a fundamental change in approach and 
a lot of people from each specialism.

The W3c horizontal review groups have expressed concern with adopting 
this work mode, and through the horizontal review investigation I 
conducted earlier this year, I have to agree that finding enough people 
to integrate the different horizontal specialisms into the EverGreen 
process would be extremely hard.

We can close the gap to a certain extent, using checklists and otherwise 
educating WG participants in the different specialisms, but without 
dedicated training and continued commitment, there is a risk that 
something wil be missed.

I think that W3C should continue to look at horizontal review as part of 
wide review (issue #130), and in doing so at ways to more closely 
integrate the horizontal specialisms into the development process, but 
in the meantime I think it would be non-sensical to implement a Process 
that can't be realised in practice.

EverTeal seems to be  a Process that will enable us to move more rapidly 
with spec production, without risking the values that W3C is known for, 
and that feels like the right balance to me.

Thanks for your continued efforts Elika.

Léonie
[1] https://github.com/w3c/w3process/issues/130

On 28/08/2019 01:32, 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
> 
> 

-- 
Director @TetraLogical TetraLogical.com

Received on Wednesday, 28 August 2019 11:59:27 UTC