Tools and templates

The W3C Process describes the lifecycle of chartered groups. At a high level, W3C approves a new Working Group or Interest Group charter after a series of reviews intended to improve the quality of the charter and generate interest in the work. The reviews typically happen in this order:

In this document we describe the operational aspects of these reviews.

Timing: Please note that these reviews take time, and people working on charters should expect the entire process to take multiple months.

Note: Group closures are addressed in other documentation.

New groups

Discussions for new work happen in a variety of venues, including Member discussions, Workshops, Working / Interest / Community Groups, and the Team.

Within the Team, the Strategy Team manages the charter development process, including allocation of staff resources. The Strategy Team tracks charters through the process via the pipeline tool.

Charter preparation

These are the recommended steps for any party preparing a charter for a new Working Group or Interest Group:

Check readiness
For a Working Group charter, review: W3C Recommendation Track Readiness Best Practices, Tips for Getting to Recommendation Faster, and How to transition work from a Community Group to a Working Group.
Draft charter
Use the charter template to create a draft charter, ideally on GitHub. This is where substantive discussion of the charter should take place, including issues and pull requests. Note: There are ongoing discussions about making it easier for people to find draft charters, e.g., by using a single GitHub repo for all draft charters.
Inform Strategy Team
When ready (e.g., after sufficient discussion among stakeholders has taken place), inform the Strategy Team by creating a new charter issue in their pipeline. The Strategy Team will use this issue to provide updates on the charter's progress through the process. Discussions of the charter's content should continue to take place in the charter's own repo.

Strategy Team role

When a new charter issue has been raised, the Strategy Team Lead assigns a staff member to shepherd the charter through the remainder of the process, the charter shepherd is the “assignee” of the issue in the pipeline. The Strategy Team typically discusses proposed charters at its regular meeting or on its mailing list. Note: If the Strategy Team Lead cannot identify a staff member, there may be delays in advancing the charter through subsequent reviews.

The charter shepherd (on behalf of the Strategy Team) roles include:

Evaluate readiness
Let the proponents know if the charter is not well-formed (per the template and per Process section "content of a chartera>"); if it is perceived to be harmful to the Web; or if it is not a priority at the current time.
Request advance notice to AC
If and when satisfied with the charter, raise awareness by requesting that the W3C Communications Team send an advance notice to the W3C Advisory Committee; for details see how to send advance notice of work to the Advisory Committee. Record in the pipeline issue that advance notice has been sent.
Timing: The exact timing of the advance notice may vary from charter to charter. In practice, if the advance notice would precede the formal call for review by only a short delay, we skip the advance notice.
Request horizontal review
Soon after, or in parallel, initiate horizontal review. This is done by adding the "Horizontal review requested" label to the issue in the pipeline.
Timing: Horizontal reviewers will usually respond within two weeks, though it is wise to allow for additional time. The charter shepherd may use the team-horizontal list to reach all the horizontal reviewers.
Horizontal reviews are not required for Groups that do not hold technical discussions, such as the Patents and Standards Interest Group.
Prepare for TiLT Review
Request approval from TiLT
When the charter shepherd is satisfied that as much progress as possible has been made, they request approval from TiLT. Record in the pipeline issue that a TiLT decision has been requested. TiLT informs the charter shepherd of their decision in the pipeline issue.
Timing: Allow approximately 2 weeks, but see Timing of responses from TiLT for details.

If approved, the charter shepherd works towards Advisory Committee Review.

Advisory Committee Review

In this part of the process, the charter shepherd (on behalf of the Strategy Team) roles are:

Prepare for AC Review
Work with the W3C Communications Team to organize Advisory Committee review of a charter (see implementation details for the review).
Monitor AC Review
Once the AC Review is underway, monitor responses and manage any Formal Objections. Ensure that the charter receives sufficient support from the Membership.
Timing:
Manage changes resulting from review
As a result of review, make any requested very minor changes (in place) to the charter. If substantive changes are proposed, then initiate review of those proposed changes. In either case, the Team follows a process for managing changes to charters after review.
Request approval from TiLT
Once the review has ended and Formal Objections are addressed, the charter shepherd requests approval from TiLT. Record in the pipeline issue that a TiLT decision has been requested. TiLT informs the charter shepherd of their decision.
Timing: Allow approximately 2 weeks, but see Timing of responses from TiLT for details.

If approved, the charter shepherd then works with the W3C Communications Team to announce the decision.

Existing groups

Here we describe the operational aspects of extending or modifying the charter of an existing group.

In these processes, a group's Team Contact typically plays the role of the charter shepherd.

Request for short-term extension

The W3C Process describes the charter extensions and when they may occur. No Advisory Committee review is required for short-term extensions. Since 2015, the Team has adopted a policy on group charter end dates: a charter may only be extended without AC review for six months or less, otherwise it must recharter.

For a short-term extension, the charter shepherd roles are:

Request approval from TiLT
The charter shepherd requests approval of the short extension by TiLT.
Timing: Allow approximately 2 weeks, but see Timing of responses from TiLT for details.
Request extension notice
If the decision is positive, request that the W3C Communications Team announce an extension.
Let the group know
The W3C Communications Team inform the group that its charter has been extended.

Request for rechartering

A group recharters when it wishes to change its charter or extend it longer than six months.

In these processes, the roles of the charter shepherd are:

Record group decision
The group should discuss and record a formal decision to request extension or to recharter.
Follow process for creating a charter
The handling of rechartering is almost the same as for new charters. Note that, in addition to any content changes, the charter may need to be updated if the charter template has changed. Furthermore, the template tool will prompt for the inclusion of Patent Policy language and otherwise help you meet the list of charter requirements in the Process. For existing groups, the charter assistant helps in producing the list of exclusion drafts.

Implementation details

The following sections are mostly intended as instructions to the Team and are included here for transparency.

Sufficient Member support for a charter

Generally, the Team will expect to receive reviews for Charter proposals from at least 5% of the Membership. If the 5% threshold is not met, the Charter may still be approved, but additional scrutiny is warranted, and resource allocation may be limited. Additionally, the Team will continue to consider the number of declarations of intent to participate or implement the output of the work group.

Given the diversity of work underway in the Consortium, including groups that focus on horizontal reviews (e.g., accessibility, security, and internationalization), as well as technologies that are initially focused on by some segment of the Web's stakeholders, there are times where exceptions to this practice may be considered. In those cases, the Team will document reasons why the exception is made.

Tips to speed up the process

Parallelize where possible:

Organizing the Call for Review

Note: Team Contacts should ensure that their work group participants are aware there is a review in progress.

The Team Contact:

The W3C Communications Team encourages the charter shepherd to include as part of the request, a draft Call for Review, created by using this template (even if the URI to the questionnaire may not yet exist).

The W3C Communications Team (or the motivated Team Contact) builds a Call for Review questionnaire. The URI for the questionnaire is added to the Call for Review announcement to members. In case of renewal of an existing charter, it is also useful to include a diff (you may wish to use the HTML diff tool) between current and proposed charters in the Call for Review questionnaire.

Once the Head of W3C Communications (or delegate) has approved the Call for Review and the questionnaire, the W3C Communications Team:

  1. Sends the Call for Review to w3c-ac-members@w3.org.
  2. Sends a version of the announcement to public-new-work@w3.org (archive). Use this template (and see the example). The announcement must include:
  3. Send the same email to new-work@ietf.org. Note: public-new-work@w3.org used to cc new-work@ietf.org but due to mailing list configuration issues, we stopped that practice.

Managing changes to charters after review

If there are only very minor changes to a charter resulting from the review, the (future) decision includes the original charter URI and an explanation of the changes and their rationale.

If substantive changes are proposed in response to charter review, the Team Contact must send the charter with proposed changes, the HTML diff, and an explanation of the changes and their rationale to all who reviewed the charter, copying the member-charters-review@w3.org member-archived mailing list, accompanied by a request for response (with a deadline of a minimum of one week for response time) if reviewers have concerns or if the changes would alter their reviews. If the work continues or derives from an existing group or community effort, the Team Contact should also send the HTML diff and a public rationale to that group or community. These communications should note that W3C has not yet approved the charter.

Suggested wording: Please let us know by [date+1 week] if you have concerns or if this change would alter your review.

If anyone expresses new concern in response to the re-review, the Team may attempt to resolve the concern (with re-review), formally open a new AC review, or the W3C Council may treat it as an objection and overrule it.

If there are substantive changes, before any announcement, the Team Contact:

  1. Mints a new URI for the version of the charter that includes the changes. In the "Charter history" section of the charter, please link to the original (reviewed) charter.
  2. Modifies the original charter in place with the following status sentence at the top:
    <p class="todo">This charter has been replaced by <a>[a newer version]</a>.</p>

Announcement of W3C Decision, Call for Participation

Preparation by the charter shepherd

The charter shepherd ensures that the following are done and the following documentation is available before asking the W3C Communications Team to announce a group:

  1. TiLT has approved the group, whether or not preceded by an AC Review.
  2. The group exists in the Groups DB.
  3. All relevant mailing lists exist. If not, the Team Contact may create the mailing list(s).
  4. The main mailing list is associated with the group via the Group Service Management interface.
  5. Make sure the charter is public (since 2007, charters are public during AC review) and any final edits (e.g., addition of link to page for joining the group) have been made. If the group already exists, the new charter and the old charter should have two different URLs.
  6. Customize the "onboarding" message that will be sent to participants as they join the group.

All Working Groups and Interest Groups appear in their respective group list and have a public list of participants (except for Interest Groups that are not managed under the W3C Patent Policy).

The W3C Communications Team should try to minimize the number of messages sent to the Advisory Committee, while ensuring that each message is clear. In general, the W3C Communications Team sends one email combining the group approval (W3C Decision) and the Call for Participation.

Timing: this takes a week at most.

Organizing the W3C Decision, Call for Participation

The charter shepherd sends a draft announcement (combining W3C Decision and Call for Participation) to the W3C Communications Team (w3t-comm@w3.org) (using the template as a starting point, or sample announcement). The announcement must indicate:

In case a charter has new deliverables in-scope, it is useful to include a notice that a 45-day grace period is granted to existing participants of the group under the previous charter, who will then need to re-join the group.

In case the new charter doesn't have new deliverables involving new patent commitment, it is useful to clarify that existing participants under the previous charter will not be required to leave/re-join the group.

Note: Per the 2021-01-13 W3M resolution (team-only), the calls for participation should include guidance to consider diversity (available from the template):

Please consider diversity when proposing people to participate in W3C groups. Representation from a wider group of people, especially people from under-represented groups, is vital for creating web standards that meet the needs of the wider web community.

The announcement must also indicate when applicable:

The Head of W3C Communications (or delegate) must approve the W3C Decision and Call for Participation draft announcement before the W3C Communications Team sends it to w3c-ac-members@w3.org.
Timing: The W3C Communications Team SHOULD announce the W3C Decision within two weeks after the end of the AC review (or send an email setting new expectations). An announcement is sent whether the proposal is approved or rejected.

If the group is approved, it is a good practice that the W3C Communications Team also:

If the group is rejected, it is a good practice that the W3C Communications Team follows-up on the Advance Notice in public-new-work to close the loop for the public record.

After sending the W3C Decision, Call for Participation

After sending the W3C Decision and Call for Participation:

Team contacts should look at how to setup a new group once the call for participation is out.

Note: When we recharter a work group and the charter scope has changed, we enter the CFP into the Group DB, which triggers messages to the group participants that they must rejoin. If the new charter doesn't have new deliverables involving new patent commitment, do not register the new CFP.

Announcement of extension

When requesting that the W3C Communications Team announce a charter exension, use the charter extension template.

The W3C Communications Team then:

The Communications Team modifies (or asks the Team Contact) the Charter in place as follows:

When a group Chair is (re)appointed or resigns, shortly before/after the announcement to w3c-ac-members@w3.org [then forwarded to chairs@w3.org] (sample emails [1][2]), The W3C Communications Team (or the Team Contact) modifies the charter, including:

Revision history


Feedback is to @w3c/guidebook and is welcome on GitHub