Re: [EXTERNAL] EverTeal

I don’t understand this response so perhaps I didn’t make myself clear.

I mostly support the current EverTeal proposal, but I’m concerned about making it too complex and asking the AC to make judgments about things they are unlikely to care about.  Specifically, the distinction between regular Recommendations and Extensible Recommendations (or whatever the current term is) doesn’t seem worth making.  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.

Yes, a WG charter MUST clearly establish the WG’s scope, and its work can’t “extend” beyond that scope.  Scope is a very key aspect of AC review:  AC reps can, and want to, advise on where standards are needed, when some technology is mature enough to transition from incubation to standardization, what definition of that technology area is tight enough to encourage royalty-free patent commitments, and what standardization work is consistent with the mission of W3C.  When these considerations may change, there MUST be a re-charter.

So I propose that the various EverTeal working modes be process implementation details under the control of the WG, and not separate “tracks” or “types of Recommendations” etc. that are specified in a WG charter.  If, for example, a WG consists of a community that needs static standards for regulations (or embedded hardware, or anything hard to update) to reference, they can choose not to update them on too-fast a rhythm.




From: Florian Rivoal <florian@rivoal.net>
Date: Monday, November 11, 2019 at 8:24 PM
To: Michael Champion <Michael.Champion@microsoft.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, Jeff Jaffe <jeff@w3.org>, W3C Process Community Group <public-w3process@w3.org>
Subject: Re: [EXTERNAL] EverTeal



On Nov 12, 2019, at 6:59, Michael Champion <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com>> wrote:

If there’s a use case for the charter / AC insisting that a WG restrict itself from using the new EverTeal process improvements, I’m not seeing it

We have things like the EPUB spec, which made CSS2.1 minus some specific features a normative dependency. They didn't make CSS overall a dependency, they made a specific feature set (defined by CSS2.1 minus some things) a dependency. There's been other cases of this, for example HBBTV's normative dependency on CSS. I don't remember others off the top of my head, but I am sure there are more. These things aren't interested in a normative dependency on something with an open scope. They explicitly want to lock the scope down. If we have a kind of REC that can take bugfixes but not new features, they'll depend on that. If we cannot, they'll take normative dependencies on dated versions, miss out on bug fixes. In the worst case, this could end up causing a fork in the technology if people are particularly diligent about implementing the details of the dated version referenced.

WCAG is another example of something where fixing the scope (while allowing bug fixes) seems desirable.

—Florian