Re: EverTeal

Thanks.

A few comments.

1. In "Changes are additive", it is a little too glib to say that if you 
were happy with the old system nothing changes.  For example, if you are 
an AC rep or an attorney, you need to process an entirely new PP.  Part 
of that includes the reality that you need to process some new states: 
CRSs that may have greater frequency.

2. As a corollary to (1), we might consider separate explainers for 
different folks.  I'm not sure that each of the following categories 
require different explanations, but some of the stakeholders we have 
include:

  * AC Reps
  * Attorneys
  * Contributors
  * Active WG participants
  * Editors (especially LS style Editors)
  * Chairs

3. The first four major bullets under "What's New" can perhaps be 
couched as one major bullet - that we are finding methods to increase 
agility on the REC track in several fashions, including the possibility 
of Living Standards.  This is a major selling point of Process 2020 - 
but by breaking down the four use cases, it occludes the higher level 
purpose.  Once that is explained, it can then describe that there are 
different parts to providing this agility and describe the 4 use cases 
(in a parallel thread with Florian, I'm still thinking that three use 
cases may be sufficient).

4. What's New/CR Updates.  This section should have a bullet which 
explains the purpose - namely to have a current version on TR even while 
it takes a while to get to REC.

5. What's New/Registries.  The big story is that we are formalizing and 
creating Registries.  Yay!  The current text is merely the mechanics.

6.  PP.  I thought we also were introducing Contribution licenses?

7. I generally liked the ET Explainer.  Thank you.  As per points 4 and 
5 above, I do think that we can intermix more of the "motivation" with 
the mechanical description of "how to".

You start that when you have sentences such as "To facilitate review of 
changes, all phases allow informative annotation of proposed changes."  
But I think we can have better explanation of the motivation.  For example:

"Proper spec development allows continuous availability of proposed 
changes to the community.  The current W3C process inhibits that because 
once a spec reaches CR (and especially once it reaches REC) it becomes 
very hard to change.  This demotivates the community; actually reduces 
effort on keeping specs up to date; and does not give developers an 
accurate view of the WG's thinking or of implementations.

Process 2020 introduces the possibility of including informative 
annotation of proposed changes in W3C documents and publishing them on 
/TR.  This will solve a host of problems.  It will allow CR-level 
documents to be updated without complicated approvals, and will allow 
greater agility in updating RECs.  At the same time, it still ensures 
that nothing becomes a W3C REC without ultimately going through the 
rigors of wide review, horizontal review, implementation experience, AC 
review, and Director review.

These enhancements to annotation and publishing provide a Living 
Standards capability as a native capability of the W3C Recommendation 
Track.  For some specs, where patent commitments are desired, but the 
label of W3C REC is not considered important - the agility provides a 
method to have a Living Standards approach without ever reaching the 
Recommendations level.

In order to build these capabilities into the REC track we have made the 
REC track a bit more complex.  There are additional potential states to 
the REC track.  But for a WG taking a spec through the REC track, there 
is not much more complexity.  The new states are quite similar to the 
existing states.  And many of the transitions between states can proceed 
more automatically (in some cases without Director approval) as part of 
a general exercise of increasing agility."

8. If you choose to add an extended motivation section as exemplified in 
point #7 above, some of the other verbiage for ET might be tailored a 
bit to support the extended motivation section.

Jeff

On 11/4/2019 3:18 AM, fantasai wrote:
> And here's an explainer, as requested:
>
>   https://www.w3.org/wiki/Process2020
>
> Let us know if it needs additional explaining. ;) Or other revisions.
>
> ~fantasai
>
> On 10/23/19 11:45 PM, Florian Rivoal wrote:
>> 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
>>>
>>>
>>
>>