Fwd: Re: Ever* consensus meetings (Was Re: Fwd: Re: Everblue Standards :D)

For archive.



-------- Forwarded Message --------
Subject:  Re: Ever* consensus meetings (Was Re: Fwd: Re: Everblue 
Standards :D)
Date:  Wed, 3 Jul 2019 16:53:23 -0400
From:  Jeff Jaffe <jeff@w3.org>
To:  Michael Champion <Michael.Champion@microsoft.com>, David Singer 
<singer@apple.com>, Florian Rivoal <florian@rivoal.net>, fantasai 
<fantasai@inkedblade.net>, Philippe Le Hegaret <plh@w3.org>, Ralph Swick 
<swick@w3.org>, Wendy Seltzer <wseltzer@w3.org>



Thanks for the continued discussion today.

Minutes are at https://www.w3.org/2019/07/03-ever*-minutes.html

Executive summary

1. We all agree that both EB and EG conceptually address the continuous 
development requirement.

2. But they are also different in significant ways.  They each have 
pluses and minuses.  Based on one's view of the issues, that causes one 
to favor EB or EG, or imagine an ET (Teal).

3. Accordingly, rather than decide at this point between EB and EG, the 
common objective is to:

  * Continue to enhance each one based on the issues (such as the ones
    discussed in the minutes)
  * Find common areas and factor them out so they are independent of EB
    v EG; and also may apply directly to today's process (as we did with
    "definition of consensus" which we discussed last week; possibly HR
    is another example)
  * Develop a common presentation so that we can get more stakeholders
    in the discussion
      o The various needs and use cases which drive the need for
        continuous development
      o How each of EB and EG solve the need
      o The list of qualitative ways in which EB and EG differ (e.g.
        applies to the whole REC track; EG creates a fork of the
        process; EB has more rigorous criteria for advancement; EG has
        more granular tooling)
      o For each way that EB and EG differ - characterize  why it is an
        advantage for EB and EG
  * Armed with the common presentation, spend two hours getting AB
    reaction in Seattle
  * Informed by the AB discussion, revise and improve the presentation
    so that we can get the entire AC into the discussion.  Included in
    that is at least 30 minutes at the AC meeting in Fukuoka.  Perhaps a
    Wednesday breakout as well.

4. It is important to get some PSIG exposure and comment on EB.  We are 
running out of time since it is summer time. Florian will reach out to 
see if we can do that on 8 July - otherwise we slip to August.

5. It is important to get more comment from some of the intended 
beneficiaries.  We have a plan for WebIDL.  We need a plan for 
WebAppSec, although that may be premature.  PLH is looking at the 
Editing spec.

6. Next meeting is Monday, 22 July, same time (2PM-5PM ET, 11AM-2PM 
PT).  Before that meeting, EB and EG are mostly iterating based on 
comments to date.  Most of the "common presentation" discussion will 
happen after that call.

Jeff


On 6/27/2019 1:45 PM, Jeff Jaffe wrote:
>
> Thanks again for meeting yesterday.  Just wanted to share some 
> administrative thoughts (maybe some content as well) as a summary of 
> where we are.
>
> 1. The next call is the same time, next Wednesday.
>
> 2. Florian encouraged all of us to read the EB proposal in its 
> entirety.  I second that motion.  I did so and it was very informative 
> (I sent separate email on that).  Now I have a better understanding of 
> how EB addresses EG use cases, although I have some other concerns (in 
> the email).
>
> 3. In yesterday's meeting we had a good meta-discussion and a good 
> discussion of EG issues 1-4, and EB 1.  We will pick up with EB 2 next 
> week.
>
> 4. I believe that all 8 of us agreed that we want to solve both (1) 
> the issues of maintenance with today's REC track (aka EB use cases), 
> and (2) a continuous review process in W3C that satisfies some W3C 
> specs that are considering WHATWG (aka EG use cases).
>
> 5. We agreed that we need to have a clearer definition of Consensus 
> that meets the EG needs and is consistent with W3C norms.  We all 
> seemed to think that is possible and is independent of EG.  Wendy took 
> the action.
>
> 6. Elika took the action to socialize EB with MS2ger to ensure that he 
> is comfortable developing WebIDL with EB.
>
> 7. We did not give out a similar action for WebAppSec. Probably no 
> urgency, but we should do so at some point.
>
> 8. Mike, you have been talking about folks in Microsoft that are 
> interested in developing in a LS model.  At some point, you might want 
> to socialize EB to them and get their reaction.  Probably not urgent.
>
> 9. Elika took the action to create a dashboard of Ever* material.
>
> 10. I raised a new issue with EB (not on the list below).  My new 
> concern was that if every update cycle generates a PP Last Call, that 
> could result in a deluge of PP requests and the attorneys might not 
> accept that.  Florian opined that we could limit the frequency of 
> update cycles.  I'm not sure we've come to ground on this one yet.
>
> Anything else?
>
> Jeff
>
> On 6/19/2019 4:34 PM, Jeff Jaffe wrote:
>>
>> Not everyone got back to me with their availability for this proposed 
>> meeting.  I understand it is because we have all been flat out in the 
>> AB meeting, so no worries.  But it would help if people could respond 
>> by the end of the week since the best day to meet might be next week!
>>
>> Meanwhile, in this email I want to frame some of the key issues that 
>> I think we need to work through together:  This is a first draft and 
>> preliminary so please help out by improving the framing.  We don't 
>> need to answer every issue via email, but better framing will result 
>> in a better meeting when we do have a call.  If we can agree on the 
>> list of the problems - then in the call we can just go through them 
>> one by one.
>>
>> *Problems with Evergreen model*
>>
>> 1. Since EG is an entire new process, it is fundamentally flawed 
>> because it will create much confusion downstream and might end up 
>> undermining the REC process.
>>
>> *Proposed resolution. *I would like to stipulate that if we see a 
>> path to solve the EG use cases via EB that (a) addresses the 
>> "Problems with Everblue model" below, (b) gets a Patent Policy agreed 
>> to in a reasonable time frame, and (c) gets sign-off from use case 
>> owners - that EB has precedence and we drop EG.  Conversely, though, 
>> if we don't see a path to achieve (a)-(c) then we push hard on an EG 
>> experiment since that appears to be better developed at this time - 
>> while still addressing the other "Problems with Evergreen model".
>>
>> 2. EG uses a strong editor model and procedural consensus rather than 
>> industrial strength W3C consensus.
>>
>> *Proposed resolution. *In reality today's W3C Working Groups have a 
>> wide variety of consensus models.  I expect that we can work 
>> productively to find common ground. In one email, Fantasai seemed to 
>> say that a strong editor model is OK as long as it is not required.  
>> But if that's the case I don't see what the issue is - because EG 
>> does not require that everyone use it.
>>
>> 3. Is the decision to allow EG made in charter (issue #271)?
>>
>> *Proposed resolution. *From my perspective this is not a blocking 
>> issue.  If we find ourselves in a situation that EB does not work and 
>> the rest of EG seems good - then I think we can get a consensus on 
>> this issue as an individual issue.
>>
>> 4. Horizontal review.  I believe I have heard that people think there 
>> is a HR issue with Evergreen, but I don't understand it.  Hopefully 
>> someone can make this clearer.  It seems to be that since (a) With EB 
>> we also need more agile HR, (b) EG also has ER Snapshots, and (c) EG 
>> also potentially has RECs - that the HR for EG is no worse than for EB.
>>
>> 5. Are there other issues?  Please add here.
>>
>> *Problems with Everblue Model*
>>
>> 1. Automatic publication does not belong in this proposal.
>>
>> *Proposed resolution. *I see this as orthogonal to Ever*.  If it is a 
>> good idea we should do it irrespective of EB, EG, or EverNothing.  
>> Personally, I have not yet understood the use case.  I do understand 
>> that some specs were held up - but I don't know why.  Maybe a simple 
>> fix in internal work process would fix it.  If not, then, sure - we 
>> should move to something like the automatic publication proposal.
>>
>> 2. EB allows many successive RECs to be issued over several years 
>> even though there are objections elsewhere in the document.  I wrote 
>> a long note about this.  I don't yet understand how we can do that.
>>
>> 3. Some (e.g. Carine) have asserted that change impacts many places 
>> across a spec.
>>
>> *Proposed resolution. *Can we get some data for this?
>>
>> 4. PLH said that EB is incomplete because we don't get patent 
>> protection across the entire document.
>>
>> *Proposed resolution. *Is this true (seems to be some debate)?  Can 
>> we fix with a simple fix to the PP?  Will PSIG go for such a fix?
>>
>> 5. PLH said that EB lacks AC reviews
>>
>> *Proposed resolution. *Clarify this issue.
>>
>> 6. Fantasai pointed out that we can address some of these issues but 
>> questioned whether we could get a PP in place in time.
>>
>> 7. I am unclear whether this approach is sufficiently "Living" to 
>> address the needs of some of the use cases (e.g. WebAppSec and WebIDL)
>>
>> *Proposed resolution. * Write the proposal in sufficient detail that 
>> we can shop it around.
>>
>> 8. Are there other issues?  Please add here.
>>
>> Jeff
>>
>> On 6/17/2019 5:01 PM, Jeff Jaffe wrote:
>>>
>>> [dropping archived list]
>>>
>>> I've talked to  several of you and emailed with others about Ever* 
>>> proposals (*=green, blue).
>>>
>>> There appears to be unanimity that the process call last week did 
>>> not go well.  Even the more careful email exchange this week is 
>>> characterized more as "people are talking past each other about how 
>>> these proposals work" and less "people have crisp disagreements".  
>>> Several people have said we need quality time to carefully go 
>>> through the concerns and see where we are, so we can map a strategy 
>>> forward.
>>>
>>> That suggests a several hour phone call.  I think the eight of us 
>>> have spent the most time thinking about this and if we can get to a 
>>> consensus (or even a common understanding) I think that will 
>>> represent progress.  So I would like to schedule it with the 8 of 
>>> us, if you agree and if possible.
>>>
>>> With four of us on the East Coast; 3 on the West Coast; (one Japan, 
>>> sorry), it would be best if we had a three-four hour call in East 
>>> Coast afternoon; West Coast morning.  Are there any days we can all 
>>> make it?
>>>
>>> My availability for the upcoming period is that I could make such a 
>>> call on:
>>>
>>> June 25th (with no sleep), June 26, 27, 28
>>>
>>> July 1 (except for 30 minutes), July 2, 3, 5, 8, 9.
>>>
>>> Jeff
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject:  Re: Everblue Standards :D
>>> Resent-Date:  Mon, 17 Jun 2019 19:48:58 +0000
>>> Resent-From:  public-w3process@w3.org
>>> Date:  Mon, 17 Jun 2019 19:48:31 +0000
>>> From:  Michael Champion <Michael.Champion@microsoft.com>
>>> To:  fantasai <fantasai.lists@inkedblade.net>, Philippe Le Hégaret 
>>> <plh@w3.org>, W3C Process Community Group <public-w3process@w3.org>
>>>
>>>
>>>
>>>
>>> This thread touches on some very key points
>>>
>>>> Wide review and consensus are the two cornerstones of the W3C 
>>>> Process: its
>>>> entire purpose is to provide the scaffolding for these two 
>>>> principles to be
>>>> consistently respected, by new and inexperienced groups as well as 
>>>> old and
>>>> practiced ones. It should not be so onerous as to impede work, but 
>>>> it should
>>>> be rigorous enough to guard against inexperience, brashness, and simple
>>>> carelessness.
>>>
>>> I don't disagree that the process DOCUMENT goes into great detail 
>>> about review and wide review, but saying that wide review per se is 
>>> one of the cornerstone principles of W3C is an overstatement. Making 
>>> the *web itself* usable by people with different languages, 
>>> cultures, and varying sensitivity to privacy and security is a key 
>>> principle, but wide review is a means to that end, not an end 
>>> itself. The Process should focus on ensuring that implementations of 
>>> the specs are accessible, internationalizeable, secure, 
>>> privacy-aware, etc. but allow different WGs and "tracks" to find 
>>> different ways of assuring this.
>>>
>>> The W3C Process as practices today evolved at a time when the 
>>> https://en.wikipedia.org/wiki/Waterfall_model was dogma in the 
>>> software industry, assuming that "progress flows in largely one 
>>> direction ("downwards" like a waterfall) through the phases of 
>>> conception, initiation, analysis, design, construction, testing, 
>>> deployment and maintenance." Wide Review fits neatly into the 
>>> waterfall framework as gates controlling the downward flow. Web 
>>> technologies, however, haven't evolved this way, leading to a 
>>> mismatch between the formal process and reality, While the Process 
>>> has evolved to have fewer formal phases and more acknowledgement 
>>> that the flow often goes "upwards", it still has problems, especially:
>>> * The need for formal review at each phase by the limited pool of 
>>> "horizontal" experts and groups creates bottlenecks, which slows the 
>>> pace of standards development
>>> * The slow pace and complexity of the formal process doesn't align 
>>> well with the [https://www.w3.org/2001/tag/doc/evergreen-web/ 
>>> "evergreen web"] in which browsers are continually updated to fix 
>>> bugs and introduce new features.
>>> * Maintenance of Recommendations often doesn't happen, in part 
>>> because the Process is, as the Maintainable Standards proposal put 
>>> it, "so unwieldy as to prevent continuous maintenance."
>>>
>>> This combination of "bureaucratic" overhead, slowness, and lack of 
>>> maintenance has driven key contributors several web platform 
>>> standards (HTML, URL, DOM) to work at WHATWG. We can expect this 
>>> trend to continue unless W3C's process becomes more "fluid", which 
>>> I'm using as a neutral term that covers WHATWG "living" standards, 
>>> the proposal for an "Evergreen" standards track, and the "Everblue" 
>>> / "Maintainable Standards" proposal.
>>>
>>> So in my mind, traditional wide review is just one mechanism that 
>>> WGs -- especially those whose customers can live with a 
>>> waterfall-ish working mode and pace -- can use. If WGs that have 
>>> customers that require a faster-moving approach to inform their 
>>> "evergreen" products AND can demonstrate that they have a 
>>> combination of up-front automated tests and a mechanism for 
>>> continuous improvement when problems are found, that can serve the 
>>> same function as traditional wide review.
>>>
>>> Likewise WGs can use different divisions of labor across the chairs, 
>>> editors, and pariticipants as far as determining how much up-front 
>>> consensus is needed before a spec is considered a standard (fluid or 
>>> otherwise). Some will be more comfortable with the traditional "WG 
>>> comes to consensus as determined by the chair, and the editor 
>>> implements the consensus" and others will be more comfortable with 
>>> the "editors writes down what think has rough consensus and running 
>>> code, participants either object and propose concrete alternatives 
>>> or as assumed to concur, the chair facilitates productive and 
>>> professional collaboration, and nothing is considered stable until 
>>> there are tests that pass." Or some combination of the traditional 
>>> and more WHATWG-ish style that works for some community.
>>>
>>> All this needs to be made more explicit and rigorous in the Process 
>>> Document (at least the description of how Continuous Development 
>>> https://www.w3.org/wiki/Evergreen_Standards#Continuous_Development 
>>> would work), but let's not insist that Fluid approaches follow the 
>>> same mechanisms for achieving the *goals* of wide review that the 
>>> traditional process does.
>>>
>>>
>>> -----Original Message-----
>>> From: fantasai <fantasai.lists@inkedblade.net>
>>> Date: Sunday, June 16, 2019 at 3:27 PM
>>> To: Philippe Le Hegaret <plh@w3.org>, W3C Process Community Group 
>>> <public-w3process@w3.org>
>>> Subject: Re: Everblue Standards :D
>>> Resent-From: <public-w3process@w3.org>
>>> Resent-Date: Sunday, June 16, 2019 at 3:27 PM
>>>
>>> On 6/14/19 8:35 PM, Philippe Le Hégaret wrote:
>>> > Here is a summary of the issues that I see in Everblue:
>>> > > 1. there is no way to create a snapshot of a draft *before* it 
>>> reaches > Recommendation in order to secure licensing commitments 
>>> over the entire > document. This is a significant flaw of the W3C 
>>> Patent Policy and was fixed in > the Evergreen proposal with the ERS 
>>> proposal. While getting contributions > commitment is a good step 
>>> forward, Everblue is incomplete.
>>> We have no problem including such a system; as I told cwilso it 
>>> sounds great. Just weren't sure how doable it was for Process 2020, 
>>> since the current Patent Policy does not have such a facility and it 
>>> seemed harder to get agreement on. But if there's agreement that 
>>> this is something to work on (and there does seem to be), then we 
>>> would be glad to include that in the proposal.
>>> > 2. Process 2005 was broken with regards to substantive changes in 
>>> order to fix > Recommendation:
>>> > a. It required a Working Group to make those changes (think Web 
>>> Crypto, XML, > WSDL, XPath, etc.)
>>> > b. It didn't allow for those substantive changes of third class to 
>>> get > proper call for exclusions.
>>> > > Everblue proposes to reestablish Process 2005, without 
>>> addressing the problem > of the Patent Policy. That simply doesn't 
>>> work. You must not be allowed to > publish an Edited Recommendation 
>>> without due patent policy process. Process > 2019 forces you to go 
>>> back to CR, thus triggering the 60 days period.
>>> Process 2005 required changes to go through a review period before 
>>> being incorporated into the Recommendation. The Process could have 
>>> been updated to extend that review period to 60 days and make it an 
>>> exclusion period, but instead RECs were made unmaintainable.
>>> The proposal here is to recreate a process for reviewing and 
>>> approving direct changes to a REC. Whatever reviews need to happen 
>>> can happen during the review period of those changes--if it needs to 
>>> be 60 days long so be it--but there's only one formal review phase 
>>> and the spec itself remains REC during this review.
>>> > All of the other requirements for CRs would have to be justified 
>>> in *any* case (wide > review, implementation, etc.). So, I don't 
>>> understand what you gain by > republishing directly (besides 
>>> avoiding republications of a CR and a PR > document). You don't have 
>>> to drag the entire spec back down to CR with you.
>>> It's only the delta that is being reviewed. This is an important 
>>> distinction.
>>> > You keep shooting down the Evergreen proposal because of its 
>>> continuous wide > review aspect. The current Process and Everblue 
>>> identify a specific point in > time in the Process where a check is 
>>> made. The current trends are to do > reviews often and early, rather 
>>> than once and last minute. Evergreen, > Everblue, or others, we'll 
>>> need to promote a system that facilitate those > often and early 
>>> reviews imo.
>>> This is a critical misunderstanding. The current REC track process 
>>> **DOES NOT SAY** that wide review should happen at CR, and in fact 
>>> explicitly encourages it to happen earlier. (The tendencies of 
>>> groups to review late in the past is one of the key reasons the LCWD 
>>> stage was dropped: to encourage reviews to happen earlier by 
>>> removing a clear opportunity to be late.) We are not suggesting that 
>>> this be changed. We wholeheartedly support continuous horizontal and 
>>> wide review, and believe that it should be a process that starts 
>>> early on, as described in the 2019 Process. [1]
>>> What Evergreen lacks, and the REC track does have, is check points 
>>> to verify that this review has happened.
>>> Under the REC track, you should have early and continuous wide 
>>> review. However, if the Editor+WG fail to solicit review, or fail to 
>>> respond to the comments sent their way, this should be caught when 
>>> trying to enter CR.
>>> Under the Evergreen proposal, you should also have early and 
>>> continuous wide review. However, if the Editor+WG fail to solicit 
>>> review, or fail to respond to the comments sent their way, there is 
>>> no point when this failure will be caught.
>>> Wide review and consensus are the two cornerstones of the W3C 
>>> Process: its entire purpose is to provide the scaffolding for these 
>>> two principles to be consistently respected, by new and 
>>> inexperienced groups as well as old and practiced ones. It should 
>>> not be so onerous as to impede work, but it should be rigorous 
>>> enough to guard against inexperience, brashness, and simple 
>>> carelessness.
>>> > You're also uncomfortable with a model with a strong editor (even when
>>> > there is oversight by a Chair), yet several of our Groups already 
>>> working
>>> > like that nowadays and are happy to delegate a lot of their
>>> > decisions/implementation details to the editor(s). The Web 
>>> Performance > Working Group is one of those examples.
>>> We're not uncomfortable with a strong-editor model existing. We're 
>>> uncomfortable with a Process that restricts work modes more than 
>>> they are restricted in the current Process. Some WGs work as you 
>>> describe, sure. They do so *under the current Process*. Other WGs 
>>> don't, they use other work modes--and are not ineffective for doing 
>>> so [2]. And that's also fine. The Process creates a loose enough 
>>> framework that variation and experimentation in work modes is 
>>> possible. This is a good thing.
>>> Having a maintainable specification should not be a privilege 
>>> afforded to groups with certain work modes and not others, not 
>>> without some actual justification for why this distinction is made. 
>>> You have not provided any compelling justification for why the 
>>> Evergreen Process should have different work mode requirements than 
>>> the current REC Process. We believe the current guidelines and 
>>> constraints on achieving consensus are sufficient, and that creating 
>>> an alternative definition in the Process is unnecessary and harmful.
>>> [1] 
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2019%2FProcess-20190301%2F%23doc-reviews&amp;data=02%7C01%7Cmichael.champion%40microsoft.com%7C7e2f620642ec4af6792108d6f2a9d629%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636963208588193265&amp;sdata=Sy8%2BboIoUUgHUCWUnc9mtyDTkkbtn3k86p4HIOTrZyw%3D&amp;reserved=0
>>> [2] 
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2FTalks%2FTPAC-2018%2Fceo-update%2F%23gh-commits-groups&amp;data=02%7C01%7Cmichael.champion%40microsoft.com%7C7e2f620642ec4af6792108d6f2a9d629%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636963208588193265&amp;sdata=M5%2FHWg4F%2FikyDW7D%2B7tuvwUzJ31cXVCv89a6on8rmAM%3D&amp;reserved=0
>>> ~fantasai and Florian
>>>