Re: [EXTERNAL] EverTeal

On Nov 14, 2019, at 1:30, Michael Champion <Michael.Champion@microsoft.com> wrote:

> > I think it is not only about the WG's assessment of *its* needs, but about
> >  assessing the needs of the consumers of the WG's output.

> Yes, that’s the nub of the issue here. I don’t think the AC generally had the interest or information to make that call, but they are the ultimate judge of whether a good call was made. 

While concretely work does happen in WGs, I am not working under the assumption that they're the only valid body to discuss/decide on things. The W3C has an AC, and it is the forum for making consequential decisions. I did not understand the goal of this exercise to be moving to a WHATWG like model where WGs have all the authority, and the membership isn't really a deciding body anymore.

If the AC has no interest in what specs are going to be used for, why are they even in the business of reviewing charters? So long as they are, the AC is the right body to as "is a WG allowed to do X".

This feels like a separate can of worms.

> > If the AC at large judges that there is no value in being able to promise to the
> > rest of the world that certain documents have a fixed scope, the we
> > can merge XREC and REC and call them allRECs. But it seems to me that
> > this is a useful promise to be able to make.
 
> “Scope” isn’t really the word you want to use here, is it? “Scope” is a Term of Art in W3C to describe the patent claim space a WG can operate in. “I don’t believe anyone is suggesting that Extensible/Evolving/whatever Recommendations can exceed a WG’s chartered scope. I suggest something like “fixed content” not “fixed scope.”

I was just using "scope" in the casual english sense. If you want to be use formal terminology, XRECs allow class 4 changes, RECs don't. This is the only difference.

https://www.w3.org/2019/Process-20190301/#correction-classes

> I’m not laying down in the road here, just saying “I’m confused, and a bit overwhelmed by the complexity”.  

Comparison to Evergreen / WHATWG:
WD = evergreen PD / unofficial draft prior to WHATWG adoption
CR-update = evergreeen / LS
CR-snapshot = evergreen snapshot / LS snapshot
REC is a stage that the evergreen and WHAT-WG don't have. Unless you're proposing that we drop RECs altogether, that stage needs some fixing as well. Hence the things that are being proposed

Comparison to current REC track:
WD = WD
CR-update = ED
CR-snapshot = CR
REC = REC
  * with the nuance that RECs can be amended without going through previous stages of the pipeline

—Florian

>  
> From:Florian Rivoal <florian@rivoal.net>
> Date: Wednesday, November 13, 2019 at 2:52 AM
> To: Jeff Jaffe <jeff@w3.org>
> Cc: Michael Champion <Michael.Champion@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, W3C Process Community Group <public-w3process@w3.org>
> Subject: Re: [EXTERNAL] EverTeal
> 
> 
> 
> > On Nov 13, 2019, at 3:23, David Singer <singer@mac.com> wrote:
> > 
> > “It’s not different, it’s a variant” is a kinda strange phrase, since variance implies (requires) difference.
> 
> Not sure where you're getting that quote from, but regardless, I probably mis-phrased something along the way. Sure, REC and XREC are different. But not different in the way the WHATWG Process or the earlier proposal for evergreen were different from the REC track. Those had a totally distinct set of rules. In this case, it's the exact same set of rules, with a single difference: XRECs can use clause 6.2.11.4., RECs cannot. Everything else is the same.
> 
> 
> > On Nov 12, 2019, at 22:32, Jeff Jaffe <jeff@w3.org> wrote:
> > Isn't CSS a group that we would expect that the WG be permitted to use ET?
> 
> "permitted to use EverTeal" is not the right way to frame it. Everteal is just a set of fixes to the REC track. Since the CSS-WG is permitted to use the REC track, it is permitted to use everteal, like everybody else. And thanks to these fixes, we'd have an easier time keeping CRs up to date, or fixing bugs in existing RECs, earlier patent protection, etc.
> 
> Does that imply that I expect the CSS-WG to switch away from its current model of having modularized and leveled specifications, in favor of a (monolithic?) ever-evolving living standards approach? No, there is no indication that the CSSWG wants to do that. Having a modular system is intentional, and locking the scope of each module+level combo when a certain feature-set is stable, pushing further features into a next level (or separate module), is very much intentional as well. We could continue to do that (at least for most specs) after the new process is adopted. That work mode would just become easier to work with.
> 
> We could also do exactly the same thing using XRECs instead of RECs, but while we do want to bugfix previously published RECS, since we don't intend to add new features to completed RECs, gaining the right to do it would do nothing for us. True, it also wouldn't hurt us to have that right and not use it. However:
> 
> > On Nov 13, 2019, at 2:31, Michael Champion <Michael.Champion@microsoft.com> wrote:
> > 
> > I want WGs to have the option to create either static or “living” Recommendations depending on the group’s assessment of its needs.  This assessment could change as a spec matures and external reality changes, and the AC is unlikely to have information to add to the decision.
> 
> I think it is not only about the WG's assessment of *its* needs, but about assessing the needs of the consumers of the WG's output. Just because a group of engineers working on a spec find it more convenient to do the entire scope of their WG in a single ever-evolving document doesn't necessarily mean that the industries (and governments?) who want to refer to that document prepared to accept that its scope may change over time.
> 
> If the W3C/AC, when chartering a WG, identifies that the work it produces would benefit from being delivered in fixed-scope pieces, then we'd charter those deliverables to be RECs and not XRECs, and give the assurance to other standards bodies, governments, companies, working groups, etc that they can say "a conforming implementation of ISO-123456789 must support all the features in css-color-6", or "governmental agencies are required to publish websites that conform with WCAG 7.3", they're not attaching themselves to a moving target.
> 
> Some groups may find that restriction constraining, which makes it discuss it upfront useful, while some other groups may be fine with it, and could benefit from the ability to reliably signal that to the rest of the world by producing RECs rather than XRECs.
> 
> If the AC at large judges that there is no value in being able to promise to the rest of the world that certain documents have a fixed scope, the we can merge XREC and REC and call them all RECs. But it seems to me that this is a useful promise to be able to make.
> 
> —Florian

Received on Wednesday, 13 November 2019 16:59:47 UTC