Re: [EXTERNAL] EverTeal

> 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.

> 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’m not laying down in the road here, just saying “I’m confused, and a bit overwhelmed by the complexity”.



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