Re: [EXTERNAL] EverTeal

> On Nov 12, 2019, at 18:31 , Michael Champion <Michael.Champion@microsoft.com> wrote:
> 
> I don’t understand this response so perhaps I didn’t make myself clear.

FWIW, nor do I.  “It’s not different, it’s a variant” is a kinda strange phrase, since variance implies (requires) difference.

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


My concerns that lead to suggesting that evergreen management needs to be in the charter were for lawyers and cross-functional groups; the lawyers need to know that they have to watch for snapshots, and the cross-functional groups need to know that they need to watch for new features. A charter is a clear place (but agreed, not the only) to make that choice clear and unambiguous.  Also, I think the AC should be allowed to weigh in on suspect choices — Recs that they believe should only be revised through the revised Rec process, or the converse, Recs that would be better maintained as evergreen.

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

David Singer

singer@mac.com

Received on Tuesday, 12 November 2019 18:23:46 UTC