Meta-charter

(Rough first draft, August 2009.)

The Scheme Standardization charter of January 2004 set up a process for the creation of a single work product, the R6RS. Recognizing that Scheme standardization is an ongoing process involving multiple work products evolving concurrently as well as sequentially, we propose that there be potentially several concurrent and/or sequential working groups, each with its own charter. This structure permits working group goals, timelines, and governance to evolve independently without requiring amendment of the standardization charter itself.

Working group charters can come from any source, and will be reviewed by the community and approved by the steering committee. Each working group charter should address

• membership (who can become a member, and how)
• mailing list policy (who can send / subscribe / read archives)
• publicity (e.g.: all technical discussions must be public)
• what are the deliverable artifacts (e.g. reports)
• timeline for drafts / review / approval (see below re iteration)
• goals (e.g. minimalism, portability, compatibility, particular functionality)
• internal decision making process (e.g. consensus, 95%, majority, etc)
• anticipated external approval process (e.g. supermajority vote)
• coordination with related working groups
• initial conditions (who is chair)

Charters can be amended, renewed, or terminated by the steering committee.

We anticipate certain operating procedures that would be common to all working groups:

• Evidence that deliverable artifacts accomplish goals (e.g. implementability) must be demonstrated.
• The final submission of deliverable artifacts to steering committee for approval (the "transition request") must be accompanied by a list of all formal objections that have been raised.
• Working groups should attempt to resolve intra- and inter-group conflicts. If working groups are unable to resolve a conflict, the steering committee may be asked to mediate.

A typical working group might designate the following individual roles:

• chair — responsible for the working group's overall process and progress
• publicity officer — responsible for making technical discussions public and for soliciting formal comments
• delegates — responsible for coordinating with related working groups
• project editor — responsible for drafting and editing written documents

The overall standardization processes (but not necessarily charters) are assumed to be ongoing. Mistakes can get fixed, perhaps by charter changes. We have to assume an iterative development process, not a cataclysmic one.

A working groups is normally disbanded after its deliverable artifacts have been approved by the steering committee. Approved artifacts can be revised by proposing a new working group for that purpose.

For comparison and inspiration we should look to organizations that have a track record of generating technical specifications in an orderly and effective manner. One example: W3C process (World Wide Web Consortium).