The WG uses [http://www.w3.org/2005/06/tracker/features Tracker] to record and track [http://www.w3.org/html/wg/tracker/actions/ Actions].

+

The WG uses [http://www.w3.org/2005/06/tracker/features Tracker] to record and track [http://www.w3.org/html/wg/tracker/actions/ Actions]. Additionally, there are trackers for the [http://www.w3.org/WAI/PF/HTML/track/ A11y] and [https://www.w3.org/html/wg/media/track/ media] task forces.

The WG has no single mechanism to record and track ''bugs'' and ''issues''. However, the recommended and preferred mechanism is to use [http://www.w3.org/Bugs/Public/query.cgi?format=advanced W3C's Bugzilla]. Github Issues may be used for the specs that use Github..

The WG has no single mechanism to record and track ''bugs'' and ''issues''. However, the recommended and preferred mechanism is to use [http://www.w3.org/Bugs/Public/query.cgi?format=advanced W3C's Bugzilla]. Github Issues may be used for the specs that use Github..

Revision as of 01:20, 4 April 2014

The purpose of this wiki is to document the HTML WG'sReal Work Modes including: Participation and Communication, Meetings, Consensus, Mail List usage, links to important resources, etc.

Note the WG's Charter formally defines the general framework of the group's working mode. In all cases, the Charter and/or the W3C Process Document overrides the information in this wiki. Nevertheless, this wiki contains additional information about how the group really works and as such, this information may be particularly useful to new members of the WG.

This document is a Living Document and as such will change. Members of the WG are encouraged to edit (e.g. to update, correct, etc.) the information in this document.

Participation from the Public (i.e. non group members), via our Public mail lists is also welcome, provided comments, contributions, etc. are consistent with the W3C Patent Policy and the Working group's Discussion Guidelines. The group uses the following mail lists:

The Technical Reports Process (What is an Editor's Draft?)

This group uses Editor's Drafts (ED) which, as the name indicates, is simply the latest version of a specification an Editor maintains. An ED should be thought of as the tip of the tree i.e. a work in progress that may change at any point in time.

EDs are not formal publications by the W3C and as such, the W3C Process Document does not explicitly define their requirements (f.ex. there are no specific rules for references or style).

Those with a vested interest in a specification e.g. implementers and application developers, should use a spec's Editor's Draft and not a dated version of the ED that was published as a Working Draft in the W3C's Technical Reports repository.

The W3C Process Document defines a so-called Publication "Heart Beat" Requirement that states a WG should publish each spec as a Technical Report (TR) every 3 months. Such documents do not require the consensus of the working group to be published. Work that fails to consistently produce heartbeat documents without a suitable rationale be published as a Note. One reason for this to occur is when the active editor count for the document drops to zero.

Editors

To start work on a extension specification requires a proposal. Modularity is encouraged. Proposal need to suggest one or more editors, be able to identify independent support, be within the scope of the working group, and not attract strong objections. For best results, the proposal should identify a draft schedule and thoughts towards what exit criteria should be used. Proposals are adopted and published as a FPWD via a Call for Consensus.

Editors in this Working Group may draw from a number of sources (e.g., other specifications, bug reports, and even discussions both on W3C mailing lists and elsewhere) and have wide freedom to update (add, change, delete) text in Editor's Drafts without prior explicit consensus from the group. This method is referred to as Edit First and Review Later and is contrary to other WGs that follow a Review First and Edit Later editing model. Despite this policy, when a substantive change is made to a specification (for example, adding or removing a feature, creating a new [http://www.w3.org/TR/html5/introduction.html#compliance-with-other-specifications willful violation[, adding a normative reference, etc.), Editors are expected to create a paper trail for the change by creating a bug report and/or notifying the appropriate e-mail list.

Additionally, the W3C has asked the editors of the HTML specification to track differences with the WHATWG HTML document. All differences are to have a description or link to the rationale for the divergence.

Does this editing work mode mean WG members' input is not taken into account? No. Editors are expected to consider all inputs and to reflect that input in the Editor's Drafts.

Note: before the WG formally publishes a specification as a First Public Working Draft, Last Call Working Draft, Candidate Recommendation or Proposed Recommendation, (i.e. a copy of the spec is placed in the Technical Reports repository), WG members will be asked if there is consensus to publish and advance the specification (as described in this document's Call for Consensus section).

New editors to existing documents are appointed by the chairs. Editors may be removed by the chairs when they aren't being responsive to the group or observing consensus.

Editors are expected to produce quarterly heartbeat documents. Such documents do not require the consensus of the working group to be published. Work that fails to consistently produce heartbeat documents without an acceptable rationale will be published as a Working Group Note. One reason for this to occur is when the active editor count for the document drops to zero.

Documents may also involuntarily (as in: over the wishes of the editors for that document) be published as Note by a 3/4 majority vote cast by members of the working group.

Related resource:

WebApps' SpecEditing wiki includes information about spec editing, including Editor roles and responsibilities.

Bugs, Issues and Actions

The WG uses Tracker to record and track Actions. Additionally, there are trackers for the A11y and media task forces.

The WG has no single mechanism to record and track bugs and issues. However, the recommended and preferred mechanism is to use W3C's Bugzilla. Github Issues may be used for the specs that use Github..

(Tracker does have a nice feature that it scans all of the group's mail lists for the patterns "ISSUE-NNN" and "ACTION-NNN" (where NNN is an issue or action number). If that pattern is found, the URI of the e-mail in mail list archive will automatically be included in the database record for that issue or action.)

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

Meetings? What Meetings?

Most of the WG's specification work progresses without formal meetings. Instead, all decisions are made via the group's various mail lists, IRC and Bug databases.

The consortium usually has an annual All Working Group f2f meeting week (aka TPAC) around October and November and this group typically has a f2f meeting during that week. A second annual F2F is generally conducted around April or May.

Consensus and Call for Consensus

Consensus is a core value of the W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).

Since most of the WG's work is done without formal meetings, the group uses a Call for Consensus (aka CfC) mechanism (typically email) to formally gather input on a specific question such as Is spec X ready to publish as a Last Call Working Draft?. When a CfC is issued, an explicit response from WG members is preferred and note that the lack of a response will always be considered assent i.e. agreement with the proposal.

Most CfCs are conducted on the public-html-admin mail list and the comment period is typically one week.

Mail List Policy, Usage, Etiquette, etc.

The Consortium has formal Mail List policies and procedures yet also accommodates some flexibility on how mail lists are used:

Each W3C mailing list has its own policies regarding who may post to the list. Those subscribed to each list are generally able to post directly to the list without delay; those who are not may be subject to manual moderation (at least the first time they post.)

Subjects should be prefaced with the name of the spec (for example: [DOM4] Blah, Blah, Blah)

When you reply to a message, please use ">" as your quotation character.

Do not prefix your content with something like "[myname]". Your content will be visible to everyone because it will *not* be prefixed by the quotation character (">").

Do not write at the top "comments inline". People will know your comments are inline.

Do strip quoted text which is not relevant to your reply.

Do not write in ALL CAPS. It is considered bad form. If you need to _underscore_ something, you can do so as such, if you wanted to *strengthen* something you can similarly, and if you want to provide a certain /italic/ style, you may do that as well.

Your messages are archived. If you need to include links within your message, please use [x] notation inline, and include the relevant links at the end of the message.