The purpose of this document is to consolidate some of the Web Application Security WG's (aka WebAppSec) 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 document contains additional information about how the group really works and as such, this information may be particularly useful to new members of the WG.
All WG members are strongly encouraged to participate in all of the specifications in progress.
A WG member may participate in various ways including:
Participation from the Public, via our Public mail lists is also welcome, provided comments, contributions, etc. are consistent with the W3C Patent Policy. The group uses the following mail lists:
The W3C Process Document formally defines the Technical Report Process this group follows.
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 them.
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 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 editingmodel.
Does this does 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 in the W3C(i.e. a copy of the spec is placed in the Technical Reports repository), WGmembers will be asked if there is consensus to publish the specification.
The WG uses Tracker to record and track WebAppSec's Actions and Issues.
Tracker scans all of WebAppSec's mail lists for the patterns "ISSUE-NNN" and"ACTION-NNN" (where NNN is an issue or action number). If that pattern isfound, the URI of the e-mail in the public-webapps archive will automatically be included in the database record for that issue or action.
Since Tracker does not have an explicit bug tracking mechanism, some Editors use the W3C's Bugzilla to track bugs. See for example WebAppSec's Bugzilla components.
Bugs are for issues where the implications or implied implementations of specification text does not match the consensus understanding of the WG's intent, or for spelling, grammatical and technical errors. Issues that substantively add, change or remove features or change or reverse a stated consensus position of a specification are NOT bugs and should be addressed via the WG's primary work mode, the public-webappsec@w3c.org mailling list.
The WG'sCharter defines the Patent Policy for this group:
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.
For more information about disclosure obligationsfor this group, please see the W3C Patent Policy Implementation.
A consequence of the group's Patent Policy is that inputs for the group's specifications from non-WG participants is not permitted. See the W3C PatentPolicy FAQ titled How should Working Groups handle contributions from non-participants (e.g., meeting guests or on public lists)? for more information about contributions from non-WG participants.
Much of WebAppSec's spec work progresses via the various mail lists, IRC and Bug databases. The group has a call every two weeks from 22:00-23:00 UTC. See the WG's overview page for thenext meeting date and conference bridge information.
The consortium usually has an annual All Working Group face-to-face meetingweek (at TPAC) and this group normally has a f2f meeting during that week. Other f2f meetings will be announced on the group's overview page and mailing list.
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 much of WebAppSec'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.
CfC's are done on the public-webappsec mail list and the comment period istypically one week. The CfC via email is typically used only for advancement of specs or issues of some lasting controversy. Consensus to close, e.g. tracked Issues and Actions is generally done on the regular call.
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.)
See W3C Mailing List and Archive Info and W3CGuidelines for Email Attachment Formats for more information.
WebAppSec's 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 and if you did not attend Kindergarten, we expect our list participants to adhere to the basic principles in All I Really Need To Know I Learned In Kindergarten.
We also expect our mail list participants to adhere to the following:
WebApps uses the #webappsec channel of the W3C's IRC system. (irc.w3.org;port 6665)
An HTML interface to the W3C's IRC system is available at http://cgi.w3.org/member-bin/irc/irc.cgi. See Meeting Resources for more information about the W3C's IRC system.
The WG aims to create a comprehensive test suite for all features of aspecification is necessary to ensure the specification's robustness, consistency, and implementability, and to promote interoperability between User Agents.
The WG's main testing resources are:
http://w3c-test.org/webappsec/- HTTP root of the group's Mercurial-based testing repository
public-webappsec-testsuite- archive of the group's testing mail list
Test Facilitators - each spec's Test Facilitator is identified in theTesting column of the Publication Status table on the overview page.
Test Facilitators are responsible for approving submitted tests andreporting on the status of test coverage for the specifications underdevelopment.
The WG uses Mercurial version control for the Content Security Policy specand for test cases for all of its specs:
W3C's Mercurial Root: http://dvcs.w3.org/hg
WebApps' Root: http://dvcs.w3.org/hg/webappsec/and Mirror for easier browsing
See Mercurial Information including a Quick User's Guide and download information; short Mercurial Blog byAnne van Kesteren