Re: Followup to "Supergroups" message to AC Forum

> On Jun 20, 2016, at 12:41 , Carine Bournez <carine@w3.org> wrote:
>> Please note
>> such Groups already deal with Deliverables in a way that is not entirely
>> in line with the Process since they usually don't officially amend
>> Charters to start a new work.

They cannot (and must not) produce something that gets under the patent policy without doing so.  Obviously, all groups are free to discuss the future, and so on.

>> We really need to adapt
>> our Process to our evolving practice or our Process is pointless.

agreed.

> 
> I think it makes sense, but it would also require amending the patent policy
> so that the RF commitment and disclosure/exclusion mechanism is per-spec
> and not per-WG.

Well, let’s be careful here.  Your *commitment* is indeed per-spec.; but by joining a WG you are expecting to commit to what’s in scope, so the charter forms the envelope of your potential commitment, yes.

> The PP needs real simplification, but this is far from 
> trivial. Tracking contributions from WG Members who would commit to RF for 
> a spec and not for another is probably impossible, and definitely worse than
> the current situation.

agreed

> 
> 
>> For such Groups, rechartering would be a fast-track process and I really
>> mean it: only an update of the deliverables section. Without Membership
>> prior request or formal objection from the AC, the Charter would be
>> "updated" and not "renewed".
>> The idea is then to keep the same Charter, just updated, with start
>> and end dates updated too.
> 
> "Just updating the charter" in terms of changing the ETAs was(is) already 
> possible (charter extensions), but declared not desirable a couple of years 
> ago. The proper "rechartering" is because of the needed RF commitments for
> the new deliverables. That's where there's room for PP simplification,
> to try to fix your points 2 and 3 above.

I think that re-chartering should not be hard; we should work on the reasons it is hard.

> 
> 
>> B. Single-Purpose Working Groups
>> --------------------------------
>> 
>> These are Working Groups expected to work on a well-predefined set
>> of deliverables and shutdown upon completion. They're not expected
>> to need an extension, although it could happen from time to time.
>> Rechartering of such Groups would retain the current expensive process.
> 
> I don't think the rechartering process is very complicated for those anyway.
> (Except when there was "per activity" rechartering, complexity was 
> artificially increased for the Staff, while may have simplified review 
> from members)
> 
> 
>> We have too often in the past hid ourselves behind IPR-related
>> rationales to enforce the presence of such ETAs in our Charters. I
> 
> I don't think it's ever been useful for IPR-related questions, actually.
> We could have just a list of deliverables covered by the charter and 
> that's it.
> 
> 
>> think it's time to acknowledge the fact the release of a Standard
>> is not always a straight line and that even with the best intentions
>> in the world, a Standard is not a Software project. In some cases,
>> giving an ETA is doable and reliable; in others, it's not and there's
>> almost nothing we can do against it. Please note this is an opinion
>> other Members also expressed. As an example, ETAs for the Deliverables
>> section of the new Charter of the CSS WG are, *again*, a problem and
>> a too complex effort. It's mostly useless, sucks our time, and let's
>> be serious, nobody ever looks at these dates again.
> 
> 
> IMHO, the interesting bits of the ETA work is to set priorities between 
> different deliverables, and evaluate estimated complexity of producing
> each deliverable (compared to each other). 
> You mentioned Testing as a particularly difficult point to estimate, almost 
> impossible to plan. I agree. However, I think it is still important that 
> a best effort strategy is used to draw the groups timelines. Just maybe 
> not in the charters, since they don't get updated that often.
> 
> 
> 
> 
> -- 
> Carine Bournez /// W3C Europe
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 20 June 2016 20:41:52 UTC