WG Charter scope and deliverables

There always are discussions about how specific scope or deliverables 
should be.  Some of the requirements met by the combination of the scope 
and deliverables in proposed Charters are:

1. W3C Membership (through their AC reps) and the Director can evaluate 
whether the WG would be useful and whether it is focused enough to 
achieve objectives, etc..
2. Possible participants can evaluate what types of patents may be 
required to be licensed (patent policy is licensing all essential claims 
in all RECs, not just one's own contributions like in a CG - so have to 
know what you're getting into and also to be able to estimate whether an 
RF spec would be practical -- so not just anything related to sensors or 
security or payments or video)
3. Community can provide feedback on what the WG should be chartered to 
do to meet community needs when Charters are public as they are being 
developed.

There are two approaches to describing scope and deliverables that 
provide those:
1. Scope is very clear and narrow so that it is clear exactly what types 
of specs could be written and what types of technologies would be 
needed.   Deliverables can then be vague or not exhaustive (it can be 
examples).
OR
2. Scope can be broad and vague, but deliverables list is exhaustive and 
carefully described so can tell what types of technologies are needed.

Deliverables generally aren't treated as exactly what spec is produced.  
Names of specs are changed.   Specs are modularized or combined.  
Instead of a "deliverable" that could equivalently be described as a 
carefully defined item in the scope.

A possible model approach for defining charter scope and deliverables:

1. Broad WG Charter Scope describing the broad bounds of what the WG is 
created for, beyond what it will actually do under the charter. (WGs 
often lay out their wider claim to what they eventually will be about - 
which makes scope sections not as useful for defining what they actually 
will do and puts more emphasis on deliverables.).

2. Restricted Scope Section.  Section that says the overall scope will 
be restricted in the Charter period to a carefully described and more 
limited set of restricted scope items.  Links to incubator specs, use 
cases, or achitecture documents would all be good to include in the 
description of a restricted scope item.  If a scope restriction item 
won't have all deliverables listed below, it should say so.  In that 
case, the description of the restricted scope item should be so clear 
that the description of deliverables in the Charter isn't needed.  e.g. 
that the restricted scope item description is as detailed and clear as a 
deliverable entry would have been without having to pretend its known 
exactly what specs are needed (while knowing enough to scope out the 
likely area for patents).

3. Deliverables.  Planned specs.  Each deliverable spec should 
explicitly link to a restricted scope item.  As above, restricted scope 
items can indicate they can add deliverables outside the Charter that 
fall within that restricted scope.

Starting work on a spec.
1. It should be possible to appeal to the Director if a W3C member 
thinks a spec is out of scope.
2. A Charter could require incubator specs from CGs or other external 
sources before starting work.  The WG does not need to use that input 
spec, but it should be clear what the spec is trying to accomplish is 
well enough understood to write a spec. Alternately, a Charter could 
require an architecture document that describes how major challenges in 
the spec can be handled.
3. WGs can explore work outside their Charter by suggesting that a CG 
take it up.  (WGs could also have their own CG where they control the 
charter of that CG and that CG could do exploratory work beyond the 
Charter).