Roles and Work Mode
The purpose of the roles and work mode is to enable the working group to constructively achieve the goals outlined in the charter.
The role of the chairs is to lead the group so that it can make progress, without necessarily driving the technical approaches.
The chairs leadership includes setting agendas, steering the group, working with human aspects of teams, running meetings, coordinating with others, working with the team, ensuring the process is followed, etc.
The role of scribes is to record all decisions, actions and issues noted by the group during meetings, as well as recording significant discussion so that topics need not be revisited.
Everyone in a meeting should consider it their responsibility to help the scribe.
- If speaking and making a complicated point - offer to type the summary into the chat yourself
- if there is an error in the log, correct it during the meeting (see Scribe Instructions)
- if the scribe needs to speak, offer to fill in
The role of the editors is to prepare drafts that accurately incorporate decisions of the working group, as well as preparing drafts for publication as decided by the working group. Editors may make changes to the editors draft first and then obtain WG approval ("edit-first"), an approach that has the benefit of showing proposed changes in context. They may also incorporate changes after they have been approved ("approve-first").
When preparing for publication the editors update the title page, status section accordingly, as well as performing validation, link, spelling and publication rules checks.
The Editors must not use the editor role to preempt WG decisions.
The test lead(s) take responsibility to track, drive and document testing for each specification they are facilitating. This includes the creation and documentation of test plans, verifying the completeness of coverage of tests, approval of submitted tests, tracking the status of interop and encouraging participation. Testing and interop are essential to progress the work and must be documented to make transitions in the process.
Team (Staff Contacts)
The team works with the Chairs to help lead the group, works to establish membership in the group, ensures the process is followed and works with the Director to advance the work appropriately, helps with technical issues and all round is very much part of the work. They may also contribute significantly to the work.
The working group will make many decisions including decisions on how to resolve technical issues, to publish working drafts, whether to advance documents in the process among others. These decisions are made by consensus (which does not necessarily mean unanimous consent although that is prefered).
Decisions should be made such that everyone active in the Working Group is able to particpate in the decision. Decisions can be made at a meeting, teleconference or F2F, if the bulk of the membership is present. In the case where the chairs believe this would not include much of the WG, a Call for Consensus (CfC) may be made. This is an email outlining the proposed resolution for a decision and calling for response within a short period, typically 1-2 weeks. No response means agreement. At the end of the period the responses are evaluated. Typically CfC's end in support (since they are typically made with knowledge of rough agreement).
There are many ways for WG members to participate, but participating in the mail list is important as it provides visibility to all members (as well as the public), and a record of the discussion for later review. Participation in meetings, especially F2F meetings, is extremely valuable as it allows discussion where text can be misunderstood. Building a social well-functioning team also has value.
The Working Group especially needs participation in creating implementation, providing implementation feedback and test cases and testing. This is often not apparent at the outset, but is essential to progress the work. Doing this early can help the group avoid re-work.
Non-W3C-member implementers can review specifications, read and participate in the technical discussions on the mail list, help write use-cases and requirements, help write tests, and otherwise contribute to the standards without joining the working group; they can grant Royalty-Free patent licenses by filling out a form; they can even file Formal Objections on technical decisions. They cannot join telcons (unless invited), attend f2f meetings (unless invited), edit the specifications, or answer polls or calls for consensus. Those privileges are restricted to W3C members or Invited experts.
Please be respectful when using the mail list and only use it for WG related material. It is helpful to provide useful subject lines, including [topic] at the start to refer to various deliverables (e.g. [anchoring], [data model], [serialization] etc). Be respectful on the list of others.
Referencing Work Group Materials
Referencing the editors draft is probably wisest to have the latest changes. When sharing a review draft for comment it probably makes sense to reference a published TR draft. Obviously drafts can change, so be warned.
The group will determine how to manage document revisions and change control.
Anyone may raise an issue, but once an issue is resolved by the WG it should not be raised again unless there is significantly new information.
When raising an issue the following 'best practice' should be used
Please provide the following information in a new issue:
- Title - A short descriptive name for the issue
- Description - A longer and complete description of the issue, state in terms of the documents
- Justification - Why is this an issue? E.g., state an architectural concern, demonstrate an interop problem, explain a use case that isn't met
- Target - What deliverable the issue is against.
- Proposal - A reasonably complete proposal for how the issue should be addressed.
- It is also appreciated if the proposed solution comes with test cases.
An issue can be recorded in github and an email will be sent to both github followers and the WG public mail list.
Minor issues such as typos and so on may be resolved by the editor, who should note the resolution with the issue and then close it.
Substantive issues should be discussed on the list; the Chairs may include in teleconference agendas as warranted.
Once the chairs believe a resolution is at hand they may start an email Call for Consensus (CfC) to ensure full participation. In a call for consensus, an email reply should be sent with a +1 to indicate support, or -1 to indicate significant concerns. In the case of concerns they should be explained, along with an alternative proposal. Silence (no response) will be interpreted as support.
Typically a CfC will be one week but the chairs may use discretion to account for holidays or other reasons.
To be considered for a call discussion, proposals and issues should be raised the week before the call, e.g. by Friday for the following Wed call. A heads up to the chairs for the need for an agenda item is helpful when it isn't obvious.
The group will determine how to manage and record actions.
Meetings will typically start on time, out of respect to those who are in attendance.