Re: When to close a Working Group?

> On Mar 11, 2015, at 12:59 , Wayne Carr <wayne.carr@linux.intel.com> wrote:
> 
> This is already in the Process 6.2.8  https://dvcs.w3.org/hg/AB/raw-file/356968630e27/cover.html#GeneralTermination
> 
> Current: "A Working Group or Interest Group charter specifies a duration for the group."  It then goes on to say: "The Director, subject to appeal by Advisory Committee representatives, MAY close a group prior to the date specified in the charter in any of the following circumstances:"  and then it lists reasons like "There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C."
> 
> If it turned out a WG was chartered to do something completely useless or harmful or if the WG has no chance of success, the above is sufficient to close it if the Director and AC agree (AC because they can appeal and override).
> 
> That seems clear that the Working Group closes when the Charter expires (the Director can no longer close it after that for the reasons it can usually be closed early), but some WGs don't currently act like that is true - and that isn't good.  We should change the language to explicitly say the WG closes when the charter expires.
> 
> Suggested Change: "A Working Group or Interest Group charter specifies a duration for the group.  The group closes on that date if the charter is not extended or the Working Group is not re-chartered."  (with links for extended and re-chartered)
> 
> Related issue:  As people noted below, the AC review can decide not to renew charters.  That is a reason not to allow long Charter extensions, rather than re-chartering where an AC Review happens.  Extensions should only happen if the WG is so close to completion that review by the AC isn't useful or if there was an unexpected delay in rechartering.  Extension shouldn't be allowed to exceed a brief period like 3 months beyond the AC approved duration.
> 

We certainly hope to get to a situation where there are no groups operating out of charter. As recently suggested, we are looking at a system change where we ensure that charters are always set to expire on quarter boundaries.  We then expect the team to have quarterly meetings, and look at

* charters expiring at the end of the next quarter (6 months away): start working on either the new charter or the extension request
* charters expiring at the end of this quarter: get that new charter out for AC review, or the extension requested and announced
* charters that have just expired; either panic and get an extension request PDQ, or close the group

We are also considering tightening it up so that no-one can join a group after the charter has expired, and publication is much harder.

Charters should not be such a grind, of course.  Getting better and more agile at writing descriptions of what our groups will do would be good.

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 11 March 2015 21:52:04 UTC