Re: Finalizing Second Screen Presentation WG draft charter

On 2014-06-23 01:36, Francois Daoust wrote:
> 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".

That remaining wording is fine.

>
>
>> 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.

I think the CG has to prepare its own new charter if it wants to work on 
extension specs or other new specs.  The only spec it is allowed to work 
on now is the one it is passing to the WG.  The CG charter says: "The 
group will ONLY produce Specifications listed here. To add any 
additional specifications, the Charter must be amended by the process 
described below. All deliverables for which the CLA patent section 
applies must be designated as such here."

The CG could create a new Charter that allows it to continue work on the 
second screen presentation API until the WG forms for that one. And it 
could add other new deliverables for the work that isn't planned to move 
to the WG.


>
> Francois.
>
>

Received on Monday, 23 June 2014 16:30:25 UTC