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

This document is a Living Document and as such will change. Members of the group are encouraged to edit (e.g. to update, correct, etc.) the information in this document. Comments about this document are welcome via the public-webapps@w3.org e-mail list, using a subject prefix of [WorkMode] ....

www-dom - for discussions about the group's DOM specs (as well as the HTMLWG's DOM specification)

public-editing-tf - for discussions about Editing APIs. This list is used by the joint task force between WebApps and HTMLWG.

public-webapps-bugzilla - this list gets an e-mail for every one of the group's Bugzilla events. (Note: this list can generate a relatively large amount of e-mail, peaking with over 700 messages in one month during 2013.)

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.

Editors

Editors in this Working Group have wide freedom to update (add, change, delete) text in Editor's Drafts without 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, adding a normative reference, etc.), Editors are expected to create a paper trail for the change such as creating a bug report and/or notifying the appropriate e-mail list.

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

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 the specification (as described in this document's Call for Consensus section).

Resources:

WebApps' SpecEditing wiki includes information about spec editing, including Editor roles and responsibilities, and links to the various document validators.

Normative References

A significant delay in the progression of a specification can occur if the features of a normative reference are not considered stable. More specifically, if specification A uses features in normative reference B, the features of B must be considered stable before specification A can be published as a W3C Recommendation.

The following documents provide information about normative reference best practices and policy:

Bugs, Issues and Actions

The WG uses Tracker to record and track WebApps' Open Actions such as administrative tasks. Tracker actions should not be used for specification issues such as bugs.

The WG has no single mechanism to record and track specification bugs and issues. However, the recommended and preferred mechanism is to use W3C's Bugzilla. Some Editors use Github and in those cases Github Issues should be used (and not Bugzilla).

(Tracker does have a nice feature that it scans all of WebApps' mail lists for the patterns "ISSUE-NNN" and "ACTION-NNN" (where NNN is an issue or action number). If that pattern is found, the URL of the e-mail in the list's 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 WebApps' specification work progresses without formal meetings. Instead, [almost] all of the technical work is done via the group's various mail lists, IRC and Bug databases.

Editors and active collaborators are encouraged to have spec-specific distributed meetings to discuss high priority bugs, to gather input on a specific topic, etc. To facilitate broad participation in these meetings including participants from across the globe, please note:

"Virtual" meetings (teleconf, etc)

Meetings must be announced on the relevant e-mail list at least 24 hours before the meeting will begin and much earlier is highly recommended (according to the relevant bit of W3C Process there should be at least one week).

The announcement should include a day + time that is acceptable to the expected participants. If that information is not known, a related discussion should begin before the meeting announcement such that a mutually agreeable time is known when the meeting is announced.

Physical meetings (aka face-to-face meetings)

For Face-to-face (f2f) meetings, there should be 8 weeks notice of the city and date/time. Exact venue information is not required so early, but it is helpful especially in large cities so people traveling can get appropriate accommodation.

The chairs and staff can help organise invitations for people who need them to obtain a visa, given sufficient notice.

The consortium usually has an annual "'Technical Plenary and All Working Group face-to-face (f2f) meeting week (aka TPAC) and this group typically has a f2f meeting during that week. The dates/locations are generally known a year or more in advance, and historically WebApps has met on the first 2 days of the event.

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 WebApps' 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 be published 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 conducted on the public-webapps mail list (or one of the group's other Public mail lists that is more appropriate) and the comment period is typically one week. However, in some rare cases, for example when Member confidentially is an issue, the Member confidential member-webapps mail list is used.

Strictly speaking, a formal CfC is not needed to publish a new Working Draft of a document. Consequently, the group does not conduct a CfC when an Editor would like to publish a new WD (as a Technical Report). However, when an Editor does want to publish a new WD, we expect the publication to be preceded by an announcement on the relevant Public list. We typically title these announcements as Public Service Announcement (PSA) and the PSA is made by a Chair (example PSA).

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 short 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 [n] notation inline (f.e.x [1]), and include the relevant links at the end of the message.

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. The group uses the W3C's web-platform-tests Github repository for all of its test suites. The group's tests use the wg-webapps label.

(A very small number of tests are still be stored in Hg/Mercurial and/or CVS but eventually, all such tests will be moved to the W3C's Github repository.)