Re: [EXTERNAL] EverTeal

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

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 02:02:59 UTC