PointerEvents/WGCode

The purpose of this document - aka The WG Code - is to describe some of the Pointer Events WG's actual working processes including: Call for Consensus, Decision Process, Meeting Regrets, etc.

Note the group's Charter formally defines many aspects of the group's working processes. 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 as well as outsiders interested in this group's work.

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

Consensus and Call for Consensus (CfC)

Consensus is a very important part of the W3C process and is formally codified in the Process Document as follows:

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 group's technical work is done asynchronously (e.g. via the mail list), the group may use a Call for Consensus (aka CfC) mechanism (typically e-mail) to formally gather input on a specific question such as Is spec X ready to publish as a Last Call Work ing Draft?. When a CfC is issued, an explicit response from group members is preferred and encouraged, and note that the lack of a response will always be considered as agreement with the proposal.

Most CfC's are done on the public-pointer-events mail list and the comment period is typically one week. However, in some rare cases, for example when Member confidentially is an issue, the group's Member-only mail list may be used.

Participation and Regrets Policy

The group's charter formally defines the Participation expecations including the requirements for Editors. In addition to this process:

• If an Editor or other active contributor is not able to attend a group meeting and a relevant discussion and/or decision is expected, those active participants are expected to send regrets before the meeting. (The regrets may be sent to the either of the group's mail lists, the group Chair or the group Staff Contact.)

Decision Process

The charter formally defines the group's Decision Poliy. In addition to this policy:

• The group may make decisions during meetings
• Asynchronous Call for Consensus (CfC) will be used to determine consensus on a question, issue, etc.
• If an active participant does not attend a meeting and that participant sent advanced regrets, the group should not make a final decision until such participants have provided input on the decision

Editing Policy

Editors in this group have wide freedom to update (add, change, delete) text in Editor's Drafts (ED) without explicit consensus from the group. This method is referred to as Edit First and Review Later and is contrary to other groups that follow a Review First and Edit Later editing model.

Does this does mean group members' input is not taken into account? No. Editors are expected to consider all inputs and to reflect that input in the ED.

Note: before the group formally publishes a specification as a Technical Report (i.e. a copy of the spec is placed in the Technical Reports repository), group members will be asked if there is consensus to publish the specification, possibly by using a CfC.

Editor Resources:

• Old WebApps' SpecEditing wiki for information about spec editing, including Editor roles and responsibilities.
• Workflow for editors and other contributors