Notice: The WebPlatform project, supported by various stewards between 2012 and 2015, has been discontinued. This site is now available on github.

W3C

The World Wide Web Consortium (W3C) is a hybrid de-facto/de-jure standards organization that focuses primarily on Web standards. It is a Web industry consortium composed of paying member organizations and community volunteers.

Website: http://w3.org

Organizational Structure

W3C has both administrative and technical staff.

Specifications are developed by dedicated Working Groups (WGs). One WG may work on one or more specifications on related topics.

Each WG has one or more dedicated W3C technical staff, called a Staff Contact, who helps develop the specification, work with WG participants to follow the process and build consensus, and manage the administrivia; each WG also has at least one Chair, usually not from the W3C staff, who sets the agenda, chairs teleconferences, and helps drive the group forward.

Working Groups are clustered into one of four domains, or focus areas, within W3C, each of which has a Domain Lead:

  • Interaction: largely client-side browser technologies, such as HTML, CSS, and JavaScript APIs
  • Ubiquitous Web: mostly technologies for mobile or alternative devices, such as Geolocation
  • Web Accessibility Initiative (WAI): accessibility technology, best practices, and policy
  • Technology and Society: policy, security, and technologies that have strong impact on cultural issues, such as privacy and identity, and open data initiatives like Linked Open Data and the Semantic Web

Working Groups have participants that are either nominees from member companies or Invited Experts. Historically, most Working Groups were member-only, with the group’s specifications only publicly visible when published as Working Drafts, but the great majority of W3C WGs now work completely in public.

Funding

W3C is funded primarily through member fees.

Communications

W3C communications are largely conducted through email lists, and through teleconferences. W3C puts an emphasis on transparency and provenance.

Each Working Group has one or more mailing lists. Most groups have all their technical correspondance on their public mailing lists. Each group may also have a member-only mailing list for administrative or sensitive matters.

Most Working Groups hold weekly teleconferences (telcons) where participants discuss proposals evaluate the merits of different options, and strategize on creating a successful technology. These telcons are minuted by one of the participants, and meeting minutes are kept for references, usually on public mailing lists.

Most Working Groups also hold regular in-person face-to-face (f2f) meetings, where they meet to discuss matters in depth. These meetings are also minuted and shared.

Process

W3C is governed by its Process Document. The Process Document sets the rules that Working Groups follow and stages by which specifications are agreed upon through a consensus of the participants and community, with transparent public review and multiple implementations.

A specification progresses through several stages to become ratified by W3C, called the Recommendation track:

Editor’s Draft (ED) (informal)

ED is the active draft before Working Group consensus; often, this is where the most up-to-date information may be found, but at the risk of being too cutting-edge, so some parts may still change. Every Working Draft starts as changes in the Editor’s Draft.

First Public Working Draft (FPWD)

W3C Working Draft FPWD is the first Working Draft that has Working Group consensus and is open for review. This is the first opportunity for participants to include or exclude their Royalty-Free patent commitments.

Working Draft (WD)

W3C Working Draft A WD is any regular iteration of the specification that has Working Group consensus and incorporates feedback. Each specification is supposed to be updated regularly, around every three months (the heartbeat requirement).

Last Call Working Draft (LC)

W3C Last Call Working Draft LC is started once the Working Group has reached internal consensus that the specification is mature and needs only a final round of review from the community and other Working Groups, as well as any implementers who are not in the WG. Since most specifications do not get adequate early review, this is sometimes the first point at which a specification gets detailed review, and based on the feedback, the specification may go through several iterations of Last Call. During LC, the WG is required to record and address to all technical feedback (though not necessarily to change the specification to match that feedback, since there are many different approaches). The minimum duration for LC is 3 weeks, but it often lasts up to a couple of months.

Candidate Recommendation (CR)

W3C Candidate Recommendation CR is the stage at which the specification is feature complete, has been adequately reviewed and revised, and is considered stable. Traditionally, this is when implementations are started and implementation feedback processed, but more recently, implementations are started at any the earlier phases, so CR is typically dedicated to creating a comprehensive test suite that prove the interoperability of each feature of the specification.

At the end of CR, the Working Group produces an implementation report, which shows the level of support in each implementation (e.g., each browser) for each test in the test suite. While there is no formal rule about the number of implementations required to exit CR, the accepted convention is that there must be at least 2 interoperable implementations of each feature. This helps promote browser interoperability, which is very important for developers.

A specification that is changed during CR must return to Last Call, unless the changed feature was marked at risk before entering CR. This is the last opportunity for Working Group participants to include or exclude their Royalty-Free patent commitments for the technology defined in the specification.

Proposed Recommendation (PR)

W3C Proposed Recommendation PR is the phase at which the specification has had adequate review and testing, and it is submitted to the W3C members for final approval.

Recommendation (Rec)

W3C Recommendation A Recommendation is the specification has had final approval by the W3C membership and the W3C Director, and is adequately tested and interoperably implemented. This is the final stage of a specification, and it is considered to be a standard. Recommendations may still be revised through new editions or versions, which must pass through the whole Recommendation track again.

As a simplified analogy, the standards process may be described in terms of the software development cycle (such as a browser lifecycle): Editor’s Drafts are nightlies; Candidate Recommendation is a release candidate branch; Proposed Recommendation is an RTM (Release to Manufacturing or Marketing); a Recommendation is a General Availability release. The next version of an actively developed specification is like the trunk or master branch.

Formal Objections

When consensus can’t be reached on a particular issue, W3C allows for the unsatisfied party to register a formal objection on technical grounds, or on grounds of violation of process. Formal objections will be considered by the Director when the decision to move forward in the Recommendation process.

Patent Policy

W3C has a Royalty-Free (RF) patent policy, which requires that Working Group participants extend a free license grant to any patents that apply to a specification from that group. This RF license is available to any individual or organization who want to implement that specification, but this license grant is revoked for any party which sues another party for a patent covered by any W3C specification. This helps keep the Web open and relatively free of patent concerns.