WorkMode

NOTE: the Web Events Working Group closed in November 2013 because it completed its technical work with the publication of the 10 October 2013 Touch Events Recommendation. As such, this document is NO longer maintained.

The purpose of this wiki is to consolidate some of the Web Events WG's Real Working Modes including: Participation and Communication, Meetings, Consensus, Mail List usage, links to important resources, etc.

Note the WG's Charter formally defines many aspects 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 embellish, correct, etc.) the information in this document.

Editors

Bugs, Issues and Actions

Note that Tracker scans public-webevents e-mails 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 the public-webevents 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.

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 much of Web Events' 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 CfC's are done on the public-webevents mail list and the comment period is one week. However, in some rare cases, for example when Member confidentially is an issue, the member-webevents mail list is used.

Note the CfC mechanism is not normally used with some of the WG's work, for instance, the Widgets group does not typically use CfCs because they have regularly scheduled meetings.

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.)

Web Events' members appreciate and encourage frank technical discussions on our mail lists but all discussions must be done in a respectful manner. Please note this respect requirement is codified in the Process Document via the following participation criteria "Social competence in one's role". Additionally, see Positive Work Environment Task Force (Member-only).

We expect participant using our mail lists to adhere to the following:

Use an attachment only when it is likely to benefit to recipients. Otherwise, place the information (in plain text format) in the body of your message.

If an attachment is necessary, avoid formats that are virus prone, proprietary or platform dependent. For example, whenever possible you should use HTML instead of MS Word, PowerPoint or PDF. (Ideally, use XHTML or HTML4.)

Testing

The WG's charter mandates the WG create a comprehensive test suite for all features of a specification is necessary to ensure the specification's robustness, consistency, and implementability, and to promote interoperability between User Agents.

Each specification has its own test suite and most specs include the test suite in the spec's directory.