Re: [EXTERNAL] EverTeal

On 11/13/2019 9:02 PM, fantasai wrote:
> Tantek pointed out that a lot of the discussion here should be moved 
> into specific GitHub issues, so based on the comments so far I've 
> posted the following issues:
>
>   * Should we adopt the EverTeal modifications to the REC track?
>       https://github.com/w3c/w3process/issues/344
>   * Should whether new features are allowed into RECs be in the charter?
>       https://github.com/w3c/w3process/issues/345
>   * Should W3C adopt the separate Evergreen Track?
>       https://github.com/w3c/w3process/issues/344

This actually is issue 343.

https://github.com/w3c/w3process/issues/343

>
> Let's continue discussions of these issues there.
>
> ~fantasai
>
>
> On 11/12/19 11:40 AM, Michael Champion wrote:
>>
>>>  My concerns that lead to suggesting that evergreen management needs 
>>> to be 
>>
>>> in the charter were for lawyers and cross-functional groups;
>>
>> Hmm, that makes sense, but it hasn’t changed my opinion.  I urge the 
>> Process CG to optimize the process for those doing the work, not 
>> those guarding the gates to ensure it is done properly.  Prioritizing 
>> gatekeepers over workers is what drove HTML and DOM to WHATWG!
>>
>> Lawyers and horizontal reviewers play an important role,  and working 
>> groups must ensure they have signed off before a spec can be called a 
>> Recommendation.   BUT I propose it’s the job of the WG itself to make 
>> this happen in a way that makes sense in some context.  Burdening the 
>> formal process with this, beyond having the ”Director”  sign off that 
>> it happened, seems excessively bureaucratic.
>>
>> *From: *David Singer <singer@mac.com>
>> *Date: *Tuesday, November 12, 2019 at 10:24 AM
>> *To: *Michael Champion <Michael.Champion@microsoft.com>
>> *Cc: *Florian Rivoal <florian@rivoal.net>, 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 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 Thursday, 14 November 2019 14:01:48 UTC