All groups have their own preferred mode of operation, rules, culture, etc. and this one is no exception. The goal of this page is to capture the work mode of the CoreMob CG so that newcomers can get up to speed in as little time as possible.
The work mode of the group has evolved and will probably continue to evolve as it continues its existence. This page will hopefully get updated as that happens.
Communication Channels
Coremob has a possibly confusing range of channels on which it carries out its work, so here’s an introduction to the various places you’ll find the output of the group and the places where you can contribute to that output.
There are quick links to a lot of these channels of communication at the top left of the CG Home Page.
The Mailing List
You can send mail to public-coremob@w3.org to make a comment on anything related to the group’s work. Please observe the Mailing List Etiquette when doing do. The list is archived and is publicly accessible.
You are very much encouraged to join the CG and hence subscribe to this list.
The Wiki
The Coremob Wiki contains information about the work of the group, meetings, links to relevant information and more.
IRC (Chat)
We use IRC to minute meetings and occasionally on an ad hoc basis to discuss matters of group interest. Our IRC channel is irc://w3.org:6665/#coremob. If you haven’t got an IRC client, and don’t want one, there’s a Web interface at http://irc.w3.org/ – enter a nickname for yourself and the channel id #coremob to join.
To date this doesn’t seem to be a place that folks hang out much unless a meeting is scheduled, but you never know, give it a shot! Given that IRC interactions are synchronous and may therefore disfavour participants who are spread across time zones, any substantive discussion taking place on IRC that concerns the whole group should be summarised to the mailing list in order to be inclusive.
Issue and Action Tracking / Bug Databases
We work to a system of Issues (specific questions we need to answer to progress our work) and Actions (work items that we ask people to carry out to get things done). Issues and Actions are recorded using W3C’s wonderful Tracker system, which links to the group’s Mailing List and notices when anyone mentions a numbered Issue or Action (e.g. by saying “ACTION-47” or “Issue-8“) in the text of an email.
Meetings
Most of the work that is done in the CoreMob CG takes place on the public-coremob@w3.org mailing list (archives) and as mentioned above, additional discussion is encouraged on the group’s IRC channel.
Some spec work is expected to progresses without any formal meetings at all, and instead, progress via the mail lists, IRC and Bug databases.
Teleconferences
Phone meetings will generally be held on the first Wednesday of each month. Details of the call are published on the Mailing List and are also listed on the Wiki.
Face to Face Meetings
At times, the CoreMob CG will meet face to face. Details are contained in the Wiki.
Version Control (Github)
Specification development is carried out on Github (https://github.com/coremob). Since we use Tracker (see above) to log issues, we don’t at present use any Github based facilities for recording Issues etc.
Polls etc.
Occasionally there’s the need for a poll, if you’re looking for a poll you’ll find it under https://www.w3.org/2002/09/wbs/52857/.
You need to be a member of the group to respond to a poll.
Policies
These are some of the policies that the group endeavors to work to.
Document Editing
Editors in this Community 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. Before publishing an official release of a document however, consensus in the broader group is required.
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 endeavour 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 CoreMob’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 document X ready to be published?”. When a CfC is issued, an explicit response from WG members is preferred and note that the lack of a response will usually be considered assent i.e. agreement with the proposal.
Most CfCs are done on the public-coremob mail list and the comment period is typically one week. However, in some rare cases these rules may change, e.g. because the review period has to match a quicker decision (which will be explained in the CfC).
Please understand that consensus is neither a vote nor some form of unanimity. Consensus is the position that leads to the lowest level of dissent, while keeping in the group’s chartered goals and the broader values of W3C and the Web community at large. Noting that consensus has been reached is the chairs’ decision. There is no appeal for such decisions, but participants may bring new technical information that has not been considered previously in order to reopen a topic on which consensus has previously been reached.
Mailing List Etiquette
Email is very easy to send and receive, but using it effectively and in a manner that is respectful of others requires greater skill. Even if you’ve been using email for a couple decades please take the time to read this section as the best practices in effect in this CG may be unfamiliar to you.
The Community Group’s members appreciate and encourage frank technical discussions on the mail list, but all discussions must be done in a respectful manner.
In the interest of keeping the signal to noise ratio high, mail list participants are expected to adhere to the following:
- Keep discussions strictly on topic. If your answer has nothing to do with the subject of the email you’re sending, it’s probably not on topic. Please consider starting a new thread instead.
- Keep discussions relevant to the Community Group’s Goals as expressed in the Group’s Charter.
- Reply inline or make the reply self-contained. To do this in Outlook, go to Options -> Mail -> scroll down to ‘Replies and forward’ -> Change ‘When replying to a message’ to ‘Prefix each line of the original message’. Trim extraneous quotes from previous emails in your replies.
- Follow basic Netiquette, such as avoiding typing in ALL CAPS.
- Please don’t CC people who are involved in the discussion. Discussion should be on the list and the list only. CC’ing people who are involved results in them getting multiple copies, or only the copy that isn’t to the list (depending on which thing is misconfigured) — which can defeat their mail filters. Neither of these states is healthy. It makes it easy for people to accidentally reply in private when they should be sending to the list. It also makes it easy for people to accidentally reply to the public because the last time they received something it was a personal message and they thought that the same would apply to the next message. — If people want to discuss things about Core Mobile, they can subscribe to the list, or read it via an archival service. If they’re subscribed, they’ll get an email whether or not you CC them. If they chose not to subscribe but read it via some other service, then your act of CC’ing them is violating their preference not to get list discussion via email.
- Encode messages using plain text.
- 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).
