- From: Carr, Wayne <wayne.carr@intel.com>
- Date: Thu, 23 Jun 2016 00:25:10 +0000
- To: "public-w3process@w3.org" <public-w3process@w3.org>
- Message-ID: <52F8A45B68FD784E8E4FEE4DA9C6E52A9D99A000@ORSMSX113.amr.corp.intel.com>
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.
A charter like that would handle concerns about the Community Group not being directed by the Working Group. Both groups can use exactly the same license, the W3C Software and Document License that WGs like Web Platform and Device and Sensor use.
The Community Group already has the type of contribution based licensing that lets it incubate new things not yet in the necessarily narrow scope of the Working Group.
CG Charter template for CGs that are guided by a W3C Working Group (this is the usual W3C CG template with a few changes to give the parent WG control) https://wayneca.github.io/CGCharterWGOwned/CGCharterWGOwned.html
(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.)
Re: Followup to "Supergroups" message to AC Forum
* This message: [ Message body<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0035.html#start35> ] [ Respond<mailto:public-w3process@w3.org?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E> ] [ More options<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0035.html#options3> ]
* Related messages: [ Next message<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0036.html> ] [ Previous message<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0034.html> ] [ In reply to<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0031.html> ] [ Next in thread<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0036.html> ] [ Replies<https://lists.w3.org/Archives/Public/public-w3process/2016Jun/0035.html#replies> ]
From: Florian Rivoal <florian@rivoal.net<mailto:florian@rivoal.net?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E>>
Date: Tue, 21 Jun 2016 12:03:25 +0900
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com<mailto:daniel.glazman@disruptive-innovations.com?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E>>, "Carr, Wayne" <wayne.carr@intel.com<mailto:wayne.carr@intel.com?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E>>, Revising W3C Process Community Group <public-w3process@w3.org<mailto:public-w3process@w3.org?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E>>
Message-Id: <8A030222-D3F9-4BD2-A4FB-C07045D40490@rivoal.net>
To: Michael Champion <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E>>
> On Jun 21, 2016, at 06:27, Michael Champion <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com?Subject=Re%3A%20Followup%20to%20%22Supergroups%22%20message%20to%20AC%20Forum&In-Reply-To=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E&References=%3C8A030222-D3F9-4BD2-A4FB-C07045D40490%40rivoal.net%3E>> wrote:
>
>> Again, there's the theory and there's the WG practice. The practice
>> is that WGs work around the blockers in the Process, on Membership's
>> firm request.
>
> As others have pointed out, the "blockers in the process" are there to make sure that the WG is operating within the boundaries of its charter, which is necessary under the patent policy.
>
> As I see it, we've already worked around the problem by creating the Community Group IPR policy which allows people to collaborate on new things so long as they commit to RF licensing any patents that cover their own contributions to a discussion. So the way forward isn't to change the Process or Patent Policy to match the practice of mixing standardization and incubation in a WG, but to change the practice so that WGs have one or more affiliated CGs where incubation takes place under an IPR policy designed for that purpose, then specs can move to a WG where broad patent commitments are made for work that is in the scope of its charter. That's what Web Platform / WICG have done.
Let's see if we can bring CGs into this conversation without going off the rails :)
I agree that the CG's IPR policy is better than the kind of limbo that not properly chartered EDs live in.
However, I think there remains very strong doubts about whether CGs themselves are a good solution to the problem we're discussing now.
Before I dive into why I think that's a bad idea in this situation (because that's somewhat long), here's an alternative proposal:
Explicitly charter WGs so that they can take on **as ED** any topic that falls within their scope without rechartering, and apply CG-like IPR rules to such drafts. Recharter (with a deliverable addition) only when you want to publish FPWD, and switch to the old fashioned WG IPR rules at that point. This isn't that far off what we do in practice already, but would get rid of the gray area for not-yet-chartered EDs.
I think incubation CGs are a good fairly good way to start working on something for which no existing WG would be a good home. They are also a good place to work on things that members of a WG have rejected when you want to try and prove them wrong.
However, I think that pushing work out of WGs into GCs when the membership of the WG is not a priori opposed to that topic (as evaluated by the usual informal consensus process rather than by rechartering) is risky.
* There's no guarantee that the membership of the WG and that
of the CG will stay synchronized, and given the different
conditions for becoming a member of either, they are actually
quite likely to diverge. If a WG and its CG do have
significantly different memberships, moving a spec from the
CG to the WG when several (or all) of its key contributors
or editors are not part of the WG is going to be a pain. It
is not clear that there will be much motivation for the CG
to hand off its work early to the WG when clear signs of
traction appear.
- If the WG takes it over early anyway, this introduces a
significant risk of fork, and history has shown we're not
particularly good a dealing with forks with TR track on
the one side and live standards on the other.
- If the WG waits too long, there won't be much else
to do other than dotting Is, crossing Ts, and rubber
stamping. This would still be useful from an IPR point
of view, but it is not clear how many people would be
motivated to work in such a WG, and even if that would
work out, we'd have thrown out the consensus approach to
spec building by moving most of it out of the WG.
* If the WG and its CG do have largely the same membership,
then the argument that moving exploratory work out to CGs
saves the membership time and resources is void. People
who do not care about a particular topic which is discussed
in a group they are part of can ignore it just as well in
a WG as in a CG. Having started the draft in a CG
actually creates more administrative work: all the overhead
needed to publish the FPWD in the WG is still there, but
in addition, you now need to document that the spec fulfills
the the CG->WG graduation criteria. This may or may not be
a lot, but it is a non-zero addition. This additional hurdle,
even if small, also increases the risk that CG specs do not
graduate into WGs early and spend a large part of their life
outside of the consensus process, leave the WG mostly rubber
stamping, or never make it to TR at all.
And if we alleviate all that by making sure that incubating CGs
have the same membership as WGs, the same consensus process,
the same editors, and a zero-effort transition between CG and WG,
then why have a CG in the first place? We'd be better off
applying CG-like IPR rules in the WGs to EDs that do not yet have
a FPWD.
- Florian
Received on Thursday, 23 June 2016 00:25:48 UTC