W3C home > Mailing lists > Public > public-w3process@w3.org > June 2016

Re: on CGs incubating for a WG - was -> Re: Followup to "Supergroups" message to AC Forum

From: Jeff <jeff@w3.org>
Date: Thu, 23 Jun 2016 03:16:05 -0400
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: public-w3process@w3.org
Message-ID: <50207252905b27ba6931be8c6ba81e76@w3.org>
On 2016-06-23 02:24, Daniel Glazman wrote:
> On 23/06/2016 02:25, Carr, Wayne wrote:
>> 
>>   Here is a Community Group Charter template for a Community Group 
>> that
>>   is controlled by a parent W3C Working Group.  The Working Group 
>> writes
>>   and modifies the Community Group Charter and names the Community 
>> Group
>>   Chairs.  The Community Group can go beyond the current scope of the
>>   Working Group Charter, but the Working Group provides the list and
>>   description of deliverables.  The Working Group modifies the 
>> Community
>>   Group charter to modify the deliverables over time.
> 
> I'm not sure to fully understand everything here...
> 
> So in such a model, the CG's list of documents remains under rather
> tight control and it cannot really "incubate" on unchartered new ideas
> without a Charter amendment coming from above? "In scope" seems to
> me totally useless then.
> 
> One of the reasons incubation CGs were originally proposed was to
> simplify the incubation process and respond to people saying our way
> of making new stuff emerge is too complicated, too long, too
> process-based. I remind all readers we have in front of us a quasi-
> informal organization able to incubate and push forward new ideas
> overnight.
> 
> Furthermore, Incubation CGs were meant to let the WGs above "finalize"
> REC track work moving the whole imagination effort down the road to
> CGs. I am under the very strong impression that Incubation CGs should
> have a scope but *not* a list of specs. Deliverables are for
> WGs. An Incubation CG should be able to start work on *anything* in
> scope w/o any kind of authorization or control from above. Then the
> above WG accepts or not to include that work in its own list of
> Deliverables. Please note the question of what happens and what's the
> negative impact on W3C's image if the decision is a "no" remains
> unresolved at this point... And I see it as a *very* important concern.
> Potentially even a critical concern.
> 
> Do we really think CG members willing to start work on ideas in
> scope will wait for a Charter amendment if it's not in the current
> list of CG or WG deliverables? Is that what we want and what we need?
> 
> In the model described above, and if I understood it correctly, I think
> we're losing the whole CG benefit and I don't see the work division
> between WG and CG useful in any way. I even see it quite harmful.

My understanding is that the CG process is so robust that it 
simultaneously allows unfettered incubation of the form advocated by 
Daniel as well as incubation with oversight as practiced by WPWG.  I 
don't see a contradiction that different CGs can do different variations 
on the model.

> 
>> (aside: I think the CSS WG has been treated differently than other 
>> groups like Web Platforms and Device and Sensor in allowing CSS to be 
>> looser in defining deliverables. That may be because there is less 
>> concern about patents in the areas dealt with in the CSS WG.  It isn’t 
>> a practical model for much of what W3C does.)
> 
> Not only that. The Membership of the CSS WG has a dual position here:
> on one hand, some of its AC-Reps care about Charter, ETAs, etc. On
> another, Members push new ideas and new drafts *all the time* and it's 
> a
> browser war. It's out of question to wait. I repeat: out of question.
> So the same AC-Reps say nothing when an unchartered FPWD is published.
> I have litterally dozens of live examples of that behaviour. And still,
> the CSS WG is an example of a WG in good shape and resisting pretty 
> well
> to the "living standards" frenzy.
> 
> That's the very reason why I am saying our process is not in line
> with our daily practice any more and we should change it.
> 
> </Daniel>
Received on Thursday, 23 June 2016 07:16:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 23 June 2016 07:16:10 UTC