Charter template for "QA Framework: Operational Guidelines"

This version:
This document is an appendix to:
Latest version of "QA Framework: Operational Guidelines":
Latest version of "QA Framework: Operational Examples & Techniques":
Lofton Henderson (lofton@rockynet.com)
Lynne Rosenthal (lsr@nist.gov)
See Acknowledgments in QA Framework: Operational Guidelines.

About this Charter template

This is an Appendix to QA Framework: Operational Examples & Techniques. It contains a template for a Working Group charter. It is complete in outline form -- all necessary sections and topics, as required by the @@W3C Process@@, are represented.

Implementers of QA Framework: Operational Guidelines (OpsGL) should be able satisfy OpsGL's charter-related checkpoints by starting with this template and filling in the designated QA-related information. (Then those bits would be merged into the draft charter, if the implementer were not using this template for drafting the whole charter, including non-QA bits.)

The substantive material about non-QA topics and items has been cut. In some cases, it is replaced with ellipsis comments, such as "[..describe mission..]." In others, the skeleton of some real non-QA content has been left in place. In all cases, the non-QA content appears (is styled) like this:

The working group will be chartered to [...describe the main aspects of the WG's mission...]

Content that satisfies an OpsGL checkpoint requirement consists of a prototype statement that would meet the requirement. The prototype statements contain fill-in-the-blank sections, which appear like this, "[--specification name--]". A WG would supply the appropriate information here to complete the prototype statement and make it an actual Charter statement.

QA content appears (is styled) like this:

Comprehensive [--test materials--] for [--specification name--]. [For OpsGL checkpoint CPx.y.]

The final bit on the prototype QA-content statements is a back reference to the OpsGL checkpoint(s) with which the Charter statement is associated (delete it when filling in the template.)

Some prototype QA-content statements don't correspond to an OpsGL requirement -- i.e., there is not a MUST requirement in some OpsGL checkpoint -- but they might help establish context and/or clarify and improve the Charter. These are indicated by a prefix of, "[QA recommended]" or "[QA optional]".

The following are some fill-in-the-blank items that are commonly used or repeated in this template::

Note. In the case that the WG is working on multiple specifications, the appropriate items in this template should be replicated. For example, if the WG is working on specifications Xblah 1.0 and Foobar 1.2, then milestone items would look like: "Basic test suite for FooBar 1.2 by August, 2003", "Basic test suite for Xblah 1.0 by October, 2003."

The charter template follows this line.


[--WG name--] WG

Every group must have a charter that describes the following:

The group's charter must be approved by the Director.
-- Process Document

Mission Statement

The working group will be chartered to [...describe the main aspects of the WG's mission...]

The [--WG name--] WG intends to execute its mission consistent with QA level [--three | five | seven | other(specify)-- ], as described in QA Framework: Operational Guidelines. [For OpsGL checkpoints CP1.1, CP1.2, CP1.3]

Scope and Work Items

Architectural Constraints

[...optional subsections like this might describe context, architectureal constraints, etc, on the work items and their scope...]

Technical Items

[...the non-QA techical items associated with the WG's main goals, e.g....]

Quality Assurance Items

Tracking and Maintenance Items

Success criteria

Production of a stable document collectively addressing each of the Work Items, at Proposed Recommendation status.

Completion of associated comprehensive [--test materials--] at Proposed Recommendation status of [--specification name--]. [For OpsGL checkpoints CP1.1, CP1.2, CP1.3]

Availability of multiple, independent, interoperable implementations of [...specification name...], and [...], including [...]


This group will commence in [...start date...] and will terminate in [...end date...].


General Working Group deliverables will include:

Specific QA deliverables will include:

Legal Data

The [...WG name...] Working Group will develop [...Royalty Free (RF) | RAND...] specification(s) as defined by the Patent Policy Working Group.


[QA optional] The planned distribution licenses for [--test materials--] are [--identify licenses--]. [Note. This information is required in the WG's QA Process Document.]

Release policy

[Sample text about general document release policy...] A list of documents actively under consideration by the group, is maintained by [...who...]. [...describe process for adding documents, modifying, etc...]. As documents stabilize, they will be released as W3C Working Drafts. No document may stay on the list of documents actively under consideration by the group for more than [...time...] without [...state any policy...]. Documents may be released sooner if consensus is achieved. If the three month deadline is reached, the current draft will be released (and not a draft from three months earlier). [...any other details of specifications consensus/release process...]

[QA Optional] The release policy for in-progress versions of [--test materials--] is [--state it--].

Relationship to other forums

QA Working Group [QA recommended]
The [--WG name--] WG will coordinate its QA work the Quality Assurance Working Group, with an appointed QA moderator as principal point of contact.
...other technical WGs...
The [...WG-name...] WG will coordinate [...etc...].
W3C Web Accessibility Initiative
The work of the [...WG-name...] WG will be coordinated with the WAI project to ensure accessibility of [...specification name...].
Device Independence Activity
The work of the [...WG-name...] WG will be coordinated with this activity, in particular the Device Independence Working Group, to ensure that [...specification name...] can [...].
Internationalization Working Group
The I18N WG will review the [...specification name...] to ensure it is adequately Internationalized.


One or more public Working Drafts, plus associated Test Suites and Implementation Reports, will be produced covering each of the Work Items, to the following schedule:

  • [Non-QA items, for example...]
  • first Working Group meeting: [...time and place...]
  • [...specification name...] requirements document: [...date...]
  • [...specification name...] Last Call by [...LC-date...]
  • [...specification name...] Candidate Recommendation by [...CR-date...]
  • [...specification name...] Proposed Recommendation by [...PR-date...]
  • [...specification name...] Recommendation by [...Rec-date...]
  • Partial [--test materials--] first public release, by [--date--]. [For OpsGL checkpoints CP1.1, CP1.4]
  • Public release of complete [--test materials--], by [--date by Recommendation--]. [For OpsGL checkpoints CP1.3, CP1.4]
  • [--other QA deliverables--] by [--date(s)--]. [For OpsGL checkpoint CP1.4]

The [--WG name--] WG explicitly ties the following milestones to QA deliverables:

  • By [--milestone--] the group will produce/publish [--test materials | other QA deliverables--]. [For OpsGL checkpoint CP1.5]
  • [Example... "By PR entrance (CR completion) the WG will publish a complete test suite."]


[...state meetings policy...]. Meeting details are made available on the W3C Member Calendar and from the [..WG-name..] WG page

Communication Mechanisms


The archived [...member-only | public...] mailing list [...specify and link it...] is the primary means of discussion within the group. [...More about confidentiality, public comment lists, etc...]

There is a public Web page on [...specification name...], at [...specify and link it...]

[QA optional] There is a public mailing list for [--specification name--], dealing with QA topics, announcements, and [--test materials--] feedback, at [--specify and link it--]. [Note. This is required for the QA Process Document (QAPD) of the WG.]

[QA optional] There is a public Web page for [--specification name--], for posting information about QA topics and [--test materials--], at [--specify and link it--]. [Note. This is required for the QA Process Document (QAPD) of the WG.]

Web site

There is a public Web page on [...specification-name...] topics, at [...specify and link it...]

[QA optional] There is a public Web page for [--specification name--], for posting information about QA topics and [--test materials--], at [--specify and link it--]. [Note. This is required for the QA Process document of the WG.]


[...specify teleconference policy...]

Voting Mechanisms

The Group works by consensus, including the use of straw polls. In the event of failure to achieve consensus, the Group may resort to a vote as described in the Process Document. [...specify further details...]


[...general participation requirements, including confidentiality, etc...].

by W3C Members

Requirements for meeting attendance and timely response are described in the Process document. Participation (meetings, reviewing and writing drafts) is expected to consume time equal to [...specify...]. [...specify any other member participation details...]

The [--WG name--] Working Group expects that its QA commitment level and QA deliverables production scenario will require [--specify amount--] WG member and staff resources. [--all | some subset(specify)--] WG members are expected to spend a portion of their time equivalent to [--specify amount--] on test materials production and other QA tasks. [For OpsGL checkpoint CP2.2]

by invited experts

[...specify invited experts policies...].

by W3C Team

[...specify W3C Team duties, functions, and any other policies...]

[...Chair's name...] <[..chair's email..]>
Last modified: $Date: 2003/02/17 04:03:17 $