- From: Jeff Jaffe <jeff@w3.org>
- Date: Fri, 30 Aug 2019 11:27:20 -0400
- To: Philippe Le Hégaret <plh@w3.org>, fantasai <fantasai.lists@inkedblade.net>, W3C Process Community Group <public-w3process@w3.org>
+1 to PLH's comments. One nit in-line. On 8/30/2019 10:09 AM, Philippe Le Hégaret wrote: > 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. I'm a bit uncomfortable characterizing this as "WG recommends to implementers". W3C's highest form of endorsement is called a W3C Recommendation, and I worry that the terminology (recommends to implementers) sounds a bit too close to W3C Recommendation. W3C shouldn't provide that level of endorsement since there could still be open Formal Objections at this stage. >> >> -> 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 15:27:22 UTC