On 1 August 2014, W3C began a transition away from this document; see the current W3C Process Document.

W3C Process Document

11 Member Submission Process

The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the Team MAY publish the material at the W3C Web site. The formal process affords Members a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Team also publishes review comments on the Submitted materials for W3C Members, the public, and the media.

A Member Submission consists of:

One or more Members (called the "Submitter(s)") MAY participate in a Member Submission. Only W3C Members MAY be listed as Submitter(s). For details about preparing a Member Submission, see "How to send a Submission request" [MEM8].

The Submission process consists of the following steps:

  1. One of the Submitter(s) sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate to ensure that the Member Submission is complete.
  2. After Team review, the Director MUST either acknowledge or reject the Submission request.

Note: To avoid confusion about the Member Submission process, please note that:

Publication of a Member Submission by W3C does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the Submitter. A Member Submission published by W3C MUST NOT be referred to as "work in progress" of the W3C.

The list of acknowledged Member Submissions [PUB10] is available at the W3C Web site.

11.1 Submitter Rights and Obligations

When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member MUST copy each of the Advisory Committee representatives of the other participating Members, and each of those Advisory Committee representatives MUST confirm (by email to the Team) their participation in the Submission request.

At any time prior to acknowledgment, any Submitter MAY withdraw support for a Submission request (described in "How to send a Submission request"). A Submission request is "withdrawn" when no Submitter(s) support it. The Team MUST NOT make statements about withdrawn Submission requests.

Prior to acknowledgment, the Submitter(s) MUST NOT, under any circumstances, refer to a document as "submitted to the World Wide Web Consortium" or "under consideration by W3C" or any similar phrase either in public or Member communication. The Submitter(s) MUST NOT imply in public or Member communication that W3C is working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) MAY publish the documents in the Member Submission prior to acknowledgment (without reference to the Submission request).

After acknowledgment, the Submitter(s) MUST NOT, under any circumstances, imply W3C investment in the Member Submission until, and unless, the material has been adopted as part of a W3C Activity.

The Submitter(s) MUST agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the W3C Document License [PUB18] and will include a reference to it. The Submitter(s) MAY hold the copyright for the documents in a Member Submission.

11.1.1 Scope of Member Submissions

When a technology overlaps in scope with the work of a chartered Working Group, Members SHOULD participate in the Working Group and contribute the technology to the group's process rather than seek publication through the Member Submission process. The Working Group MAY incorporate the contributed technology into its deliverables. If the Working Group does not incorporate the technology, it SHOULD NOT publish the contributed documents as Working Group Notes since Working Group Notes represent group output, not input to the group.

On the other hand, while W3C is in the early stages of developing an Activity Proposal or charter, Members SHOULD use the Submission process to build consensus around concrete proposals for new work.

Members SHOULD NOT submit materials covering topics well outside the scope of W3C's mission [PUB15].

11.2 Team Rights and Obligations

Although they are not technical reports, the documents in a Member Submission MUST fulfill the requirements established by the Team, including the Team's Publication Rules.

The Team sends a validation notice to the Submitter(s) once the Team has reviewed a Submission request and judged it complete and correct.

Prior to a decision to acknowledge or reject the request, the request is Team-only, and the Team MUST hold it in the strictest confidentiality. In particular, the Team MUST NOT comment to the media about the Submission request.

11.3 Acknowledgment of a Submission Request

The Director acknowledges a Submission request by sending an announcement to the Advisory Committee. Though the announcement MAY be made at any time, the Submitter(s) can expect an announcement between four to six weeks after the validation notice. The Team MUST keep the Submitter(s) informed of when an announcement is likely to be made.

Once a Submission request has been acknowledged, the Team MUST:

If the Submitter(s) wish to modify a document published as the result of acknowledgment, the Submitter(s) MUST start the Submission process from the beginning, even just to correct editorial changes.

11.4 Rejection of a Submission Request

The Director MAY reject a Submission request for a variety of reasons, including any of the following:

In case of a rejection, the Team MUST inform the Advisory Committee representative(s) of the Submitter(s). If requested by the Submitter(s), the Team MUST provide rationale to the Submitter(s) about the rejection. Other than to the Submitter(s), the Team MUST NOT make statements about why a Submission request was rejected.

The Advisory Committee representative(s) of the Submitters(s) MAY appeal the rejection to the TAG if the reasons are related to Web architecture, or to the Advisory Board if the request is rejected for other reasons. In this case the Team SHOULD make available its rationale for the rejection to the appropriate body. The Team will establish a process for such appeals that ensures the appropriate level of confidentiality.