Re: Finalizing Second Screen Presentation WG draft charter

On 2014-06-20 22:56, Wayne Carr wrote:
>
> On 2014-06-17 02:47, Francois Daoust wrote:
>> Hi Mark,
>>
>> On 2014-06-16 22:39, mark a. foltz wrote:
>>> LGTM with one question that came to mind.
>>>
>>> The proposed update reads:
>>>
>>> "Upon approval of the Working Group, the Community Group will cease its
>>> work on the Presentation API specification. It is expected that the
>>> Community Group will recharter to work on other related deliverables
>>> where it is not clear enough how to proceed for it to be a work item for
>>> a Working Group. The Working Group and Community Group will never work
>>> on the same deliverable. The Community Group is only one possible source
>>> for work under future WG Charters, but can serve to do initial
>>> exploration for some future work items."
>>>
>>> When it comes to a proposed change that is related to Web second sceen
>>> efforts, would there first be a discussion as to whether it falls in
>>> scope of the Presentation API WG (presumably as defined by the charter),
>>> and then it will be routed to the WG or CG for further consideration?
>>>   Is there a process for this?
>>>
>>> It seems like some issues like privacy, user experience, and content
>>> handling will come up in both contexts and I am wondering how we
>>> maintain consistency and cross-communication across both groups.
>>
>> I cannot think of a process that specifies how a CG and WG are to work
>> together (or how liaisons are to work in practice for that matter).
>> The CG process does not say much about co-existence of a CG and a WG
>> in particular, except to recommend that a CG "no longer develop the
>> same material in parallel" (quoting from "Parallel Activities between
>> a Community Group and a Working Group" section in
>> http://www.w3.org/community/about/agreements/ ).
>>
>> The CG process is lightweight: CGs can choose to work on whatever they
>> want, even if the topic is in scope for a WG (and can also easily
>> change their mind). The sentence "The Working Group and Community
>> Group will never work on the same deliverable" is too strong in that
>> regard. A WG charter cannot restrict a CG. I'll drop it.
>
> The problem with dropping it is that there has been concern about
> forking specs and multiple groups producing competing versions of the
> same spec.  So when there is a transfer of a spec like this it is very
> likely to come up whether this is a transfer of the spec with the cg
> stopping work on that spec or if work would continue in parallel in both
> groups.  The latter would not likely be considered a good thing in the AC.

Note I merely dropped the sentence "The Working Group and Community 
Group will never work on the same deliverable" from the draft WG charter 
because the WG cannot impose restrictions on deliverables the CG may 
decide to work on later on (say in two CG charters from now). It still 
sets expectations with regard to what the CG will do upon approval of 
the WG, in particular "cease its work on the Presentation API 
specification".


> Since the CG is producing the charter for the proposed charter for the
> WG and since the CG would also need to recharter to add new
> deliverables, the CG can decide it won't compete with the WG on specs it
> has transferred to the WG - or at least not on the one it is turning
> over to the WG now.
>
> CGs can be open ended and do whatever they want (but those can be
> difficult for some companies to join) or they can have a charter that
> says what they can do and a way to change the charter.  This CG has a
> charter that explicitly describes the specs it can produce and a way to
> change the charter to add new specs.  So for new areas of work it would
> recharter - and would drop the spec it gave to the WG.

Right, now that the draft WG charter is ready, the CG could indeed 
prepare its own new charter. That charter could clarify that the CG 
intends not to work on the same deliverables (or features) as the WG.

Francois.

Received on Monday, 23 June 2014 08:36:57 UTC