Skip to content
This repository has been archived by the owner on Nov 15, 2021. It is now read-only.

Latest commit

 

History

History
231 lines (142 loc) · 23.5 KB

WorkMode.md

File metadata and controls

231 lines (142 loc) · 23.5 KB
Raw

Work mode

This document defines and describes the Web Platform WG's Real Work Modes including: Participation and Communication, Meetings, Call for 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 document. Nevertheless, document 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 [email protected] e-mail list, using a subject prefix of [WorkMode] ....

Participation and Communication

The group's formal Participation and Communication models are documented in the Participation and Communications sections of its Charter, respectively.

Strictly speaking, only the Chairs and Editors have firm participation requirements. However, all WG members are strongly encouraged to participate in all of the specifications in progress.

A WG member may participate in various ways including:

  • Participating in discussions on the group's mail lists (see below), and/or a specification's Github repository
  • Participating in discussions on the group's #webapps IRC channel
  • Being an Editor of one or more of the group's active specifications
  • Contributing tests for the group's specifications
  • Attending any of the group's formal meetings

A WG member is only added to the group's list [email protected] . Other mailing lists listed below have to be subscribed to manually.

Participation from the Public (i.e. non group members), via our Public e-mail lists is also welcome, provided comments, contributions, etc. are consistent with the W3C Patent Policy.

NOTE: Participations

  • public-webapps - for all technical and test-related discussions except for the topics covered by another e-mail list below. WG members are automatically subscribed to this list.
  • public-html - for HTML technical and test-related discussions except for the topics covered by another e-mail list below
  • public-script-coord - for discussions about the Web IDL spec and ECMA TC39 coordination
  • www-dom - for discussions about the group's DOM specs
  • public-editing-tf - for discussions about Editing APIs.
  • public-webapps-bugzilla - this list gets an e-mail for every one of the group's Bugzilla events. (Note: this list used to have a relatively large amount of e-mail, peaking with over 700 messages in one month during 2013.)
  • public-webapps-github - this list gets an e-mail for all Github activity regarding the group's specs. (Note: this list has a relatively large amount of e-mail, with over 1,700 messages in July 2015.)
  • public-test-infra - for testing infrastructure discussions

Information for Newbies - New Group Members

New members of the group are strongly encouraged to read the group's Newbie document which includes links to important resources. New members are also encouraged to send a short introductory e-mail to the group's primary mail list.

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

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 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's 2015 Process Document indicates that if 6 months elapse without significant changes to a specification a Working Group SHOULD publish a revised Working Draft, whose status section SHOULD indicate reasons for the lack of change.

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:

  • SpecEditing 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 both Github and W3C Bugzilla to record and track specification bugs and issues. The recommended and preferred mechanism is to use Github Issues. Bugzilla usage will eventually be phased out.

Resources:

Patent Policy

The WG's Charter 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 obligations for this group, please see the W3C Patent Policy Implementation.

A consequence of the group's Patent Policy is that, although comments from non-WG participants are welcome, in general, specific input contributions for the group's specifications from non-WG participants are not permitted. See the W3C Patent Policy 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. Non-WG participants may contribute to the group's specifications if they have agreed to the terms in Licensing commitments from non-W3C Members.

Meetings? What Meetings?

Most of the group's specification work progresses without formal meetings. Instead, all of the technical work is done via the group's various mail lists, Github Issues (see the group's Github repositories), Bugzilla bug databases and IRC.

Editors and active collaborators are encouraged to have spec-specific distributed meetings (voice conferences) 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 (aka distributed 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.

All meetings

Meeting observers

It is possible for people who are not members of the Web Platform WG to attend meetings as observers. Non-members have not made any commitment to provide standard W3C royalty-free licensing, so non-members are restricted to observer status only.

Observers may listen, and participate in general discussions during the meeting. However, they must not make technical contributions, or attempt to influence an approach to a feature that may become part of the specification being discussed.

If the attendee works for a W3C member company, they are encouraged to ask their Advisory Committee (AC) representative to make them a Web Platform WG participant. Alternatively, their AC representative can make a formal royalty-free licensing commitment. They can then fully participate in the meeting.

Please note that this is to provide as much protection as possible through the W3C Patent Policy. We take the royalty-free status of W3C standards very seriously, and any attempt to work-around these basic requirements would be considered a serious breech of meeting participation.

Resources:

  • Meetings contains: information about the group's formal meetings including upcoming meetings, links to previous f2f meetings, schedules for semi-regular topic-specific virtual meetings.
  • IRC and Meeting Resources

Consensus and Call for Consensus

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 work is done without formal meetings, the group uses a Call for Consensus (aka CfC) mechanism to formally gather input on a specific question such as Is spec X ready to be published as a First Public 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.

CFCs are conducted on Github. An issue is opened on the repo for the specification, and a notification email sent to [email protected] to let the WG know. The Github issue and email will have a subject line that starts with "CFC" and includes both the subject of the CFC and the closing date.

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

See W3C Mailing List and Archive Info and W3C Guidelines for Email Attachment Formats for more information.

Group members appreciate and encourage frank technical discussions on its 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 Code of Ethics and Professional Conduct 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 email etiquette:

  • Messages should be encoded using plain text. Formats using rich text will be lost by the list archives and appear poorly to many readers before they get that far.
  • Messages should not use top-posting. See the WHATWG's top-posting guidelines for more information as well as this email from Tobie Langel for more information about top-posting and Outlook and Outlook Express.
  • 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.
  • Attachments must follow the W3C Guidelines for Email Attachment Formats, in particular: ** Avoid unnecessary email attachments. ** 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. ** Follow Web Content Accessibility Guidelines (WCAG)

Off-Topic Discussion Policy

The group's mail lists are only to be used for technical discussions of the group's specifications and related resources such as test cases.

Discussions related to general W3C-wide processes and policies are not appropriate for any of the group's mail lists and as such, discussions on those subjects are considered "off-topic".

Here is a list of documents and topics that are explicitly off-topic for the group's mail lists, including one or more appropriate discussion forums that may be used:

We expect everyone using the group's mail lists to please respect this policy.

IRC

The group uses different channels of the W3C's IRC system (irc.w3.org; port 6667) including:

  • #webapps - for Public technical discussions; this channel is continuously logged/archive
  • #wam - for Member-confidential discussions; this channel is NOT logged and should NOT be used for technical discussions

An HTML interface to the W3C's IRC system is available. See Meeting Resources for more information about the W3C's IRC system.

Testing

The group'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-webplatform label.

Resources:

  • web-platform-tests Github repository
  • Test Facilitators - each spec's Test Facilitator is identified in the Testing column of the group's PubStatus document

Github

The group uses Github repositories for all of its specifications and all of its testing resources (including test suites).

Resources:

Links to Group Resources