This document supplements the Process Document by providing best practices to resolve and decide Formal Objections.
In this document, resolving a Formal Objection means finding a solution that has no objections. Deciding means giving a yes/no answer to the question of whether an objection should be overruled (i.e., no) or sustained (i.e., yes).
W3C aims to make decisions by consensus. If there are differences of opinions, groups work to understand different points of view and reach agreement, either by compromise, or by the force of some argument. When that is working well, Formal Objections are rare, indeed.
W3C has substantial formal and informal processes to achieve consensus. The technical development process that results in W3C Recommendations requires that raised Issues be addressed by Working Groups. It is a rare event that an issue gets to the Council's desk, and this only occurs after there has been a thorough airing of all points of view in the relevant Working Group.
Similarly, most Working Group Charters are openly developed in Github. Advance Notices inform the community when there is a new Charter to look at, the Charter development process is open for people to raise issues and there is a fair effort to resolve issues prior to someone raising a Formal Objection.
The fact that Formal Objections should be rare does not de-legitimize any particular objection. On some issues there are legitimate differences of opinion that require senior review. Some topics do not lend themselves to compromise, they are inherently yes/no decisions. It could be hard to find common ground.
Nonetheless, the fact that the process is oriented towards consensus implies that before an objection gets a senior review there already has been significant work on the issue. There is generally clarity on what the W3C decision was (that is being objected to). The objector, in trying to reverse the decision, has generally pulled together their best arguments and brought them to the group. The fact that so much work should be accomplished prior to senior review should make the effort to decide a Formal Objection easier.
The Team has the responsibility to try to resolve a Formal Objection, or to come up with an analysis that might be used by the W3C Council in deciding a Formal Objection. The Team takes the early steps in processing Formal Objections.
There are different types of Formal Objections and W3C needs to make sure they are all handled properly. Here are some interesting cases that are included herein:
There is a Formal Objection to a decision in a Working Group. The Team as a neutral bystander attempts to resolve the objection. If it succeeds, W3C takes the path recommended by the Team. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides.
The Team proposes a Charter to the W3C Advisory Committee and there are objections. The Team attempts to resolve the objection even though they are not a neutral bystander. If it succeeds, W3C takes the recommended path. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides.
The Advisory Board (AB) or Technical Architecture Group (TAG) make a decision (e.g., on a process issue, or in a Statement emanating from a TAG finding) and there are objections.
It is important that even though the Team is an interested party in case 2, and the AB or TAG could be interested parties in case 3, the overall process must provide the objectivity and transparency to give the W3C Community the confidence that such cases are handled fairly.
All Formal Objections are made in response to a decision. Decisions are typically made by a Working Group as part of the Technical Report Development Process or by the Team as part of an exercise to charter a new Group.
Since W3C operates by consensus, it is always better if there can be a consensus between the group that made the original decision and the objector. The first step in processing a formal objection is for the Team to see if it can find a consensus. Even though that presumably has happened already in the Working Group, a new set of eyes might find new paths to resolution. If resolution succeeds, then that resolution becomes the new decision. If that is not successful, the Team prepares a detailed report with an analysis of the decision, objection, and its attempt to find a consensus. That report may also contain a recommendation to favor either the decision or the objection.
This report is then sent to the W3C Council, to the deciders, and to the objectors. The Council, like the Team before it, may try to find a consensus path forward. Otherwise, the W3C Council uses input from the report, the deciders, and objectors to either overrule the objection (in which case the original decision is in force), or to sustain the objection (in which case the original decision is vacated). The W3C Council also writes a report explaining their decision, which may be based on the Team's report.
When a Formal Objection is raised, the Team assigns someone to attempt to resolve the Formal Objection. That assignee is expected to follow the best practices below for this effort.
Within the bounds set by the Process, the Team decides how long the assignee has to attempt resolution and to write the report before the decision will be brought to a W3C Council. It is important that not too much time is spent in trying to resolve irreconcilable differences. Appropriate timing will depend on the complexity of the issue, and on the cooperation of the objector(s) and decider(s).
The assignee should be well versed in the topic at hand. The assignee could be the Team Contact for the relevant Working Group, the person that drafted the Charter that is being objected to, or another member of the Team who has familiarity with the situation. It is important that the assignee be perceived as unbiased with respect to the decision under review, and it is extremely important that they execute this task in a way that is as neutral and transparent as possible.
The assignee works with all participants to explore whether there is a way to resolve the Formal Objection. If the assignee believes that they have succeeded then the assignee needs ample documentation that the objection is resolved. Resolution requires both the satisfaction of the objectors and ensuring that the proposed resolution does not itself have objectors. Here are some examples:
If the objectors no longer object to the original decision, there must be written documentation that they are withdrawing their objection.
If the resolution causes a change in a technical document, then there must be a Working Group call for consensus on the revised document to which there are no objections.
If the resolution causes a change in a proposed charter, then all participants in the AC review of that charter must have an opportunity to review the revised proposed charter.
If resolution is not possible in the allocated time frame, the assignee must refer the Formal Objection to the W3C Council for decision. The steps for that are as follows:
The assignee writes a report for the W3C Council summarizing the decision and the objection.
The document is typically public.
If there are limited portions of the document which are confidential, there may be pointers to a separate confidential document. These may be summarized in the main document without compromising confidential information.
The document should have a section in which both points of view are fairly expressed.
The document should include a list of who the objectors are. If that list is confidential, it may be in the separate document.
The document should list attempts to resolve the objection and why they failed.
The document may include the assignee's recommendations and rationale whether to sustain or overrule the objection.
The report should be available for review by the relevant groups and objectors.
If any participant feels that their viewpoint is not fairly represented, a limited time effort should be expended to get all relevant information into the document.
If at the end of the alloted time the Team determines that it is not possible to get agreement on the summary document, then the Team publishes their summary and notes which participants believe that it is not a fair summary. Those participants may write up their own viewpoints.
The assignee should indicate an explicit team contact (which can be the assignee) for comments on the draft document.
The W3C Council determines who will rule on this objection and who will chair the Council.
Every person serving on the Council is expected to be sufficiently knowledgeable and thorough that they feel comfortable with the decision of the W3C Council. The breadth of the Council membership, and therefore the participation of each of its members, is key to the Council’s ability to provide an appropriate balance of viewpoints.
The W3C Council deliberates and reaches a decision to sustain or overrule the original decision.
If the W3C Council members deem that the written summaries are sufficient, they are not required to discuss with participants further, although they may do so if they wish. They may consult with deciders and objectors if they wish. See thoroughness and fairness below.
Once consultations are completed, the Chair of the W3C Council assesses the consensus of the Council, or if consensus cannot be found, calls for a vote of the W3C Council to sustain or overrule the Formal Objection.
The W3C Council publishes its decision and its rationale.
Whether the decision is to sustain or overrule, the W3C Council may include additional guidance for any of the participants involved.
If the objection is sustained, the relevant group (i.e., Working Group, or Team developing a charter) may continue their work and develop a different proposal for their document.
Each Formal Objection referred to the W3C Council has unique aspects, and the W3C Council needs the flexibility to choose how it reaches a decision. In studying a particular Formal Objection, the W3C Council should always balance several factors:
Making the correct decision for the Web.
Speed of decision making: that W3C does not get mired in objection processing.
Understanding and empathy for the objector(s).
Assuring that objection processing does not become a means for all decisions to be centralized at W3C.
Treating all objectors consistently irrespective of who the objector might be.
Workload. If processing each Formal Objection results in significant work for a very large Council, then the Council will not have time to process the workload and the Council design will not scale.
The nature of a Formal Objection is that a Decision has been made and someone has raised a Formal Objection to that Decision. The W3C Council is required by the Process to review the Decision, and choose whether to overrule the objection or sustain the objection. This section addresses the question about what information the Council has to consider.
In any individual objection, the Council is empowered to find any resolution to the objection. In addition, finding a consensus that is supported by all is always preferred. Nothing in this discussion precludes such an approach or forces an adversarial judicial proceeding. Nonetheless, there should be a clear expectation about the starting point for Council deliberations.
Objectors should not be looking at the Council to come up with new arguments to support their point of view. For example, if objectors have vague arguments of the form ”this is bad for privacy” or “this is bad for business”, they should not expect the Council to do the research to demonstrate whether their vague arguments are correct. Rather, they need to bring forward arguments which explain why something is bad for privacy and/or business—and then the Council evaluates their claims. The objector is responsible for making a compelling case to help the Council understand their concerns, and should provide evidence and references to that end.
An important role for the Team assignee is to anticipate questions the Council is likely to have during its deliberations about the Decision and the Objection, and to work with the objector(s) and decider(s) to provide that information in the Team Report.
Nevertheless, the Council should not dismiss an Objection merely because the objector or the Team did not provide incontrovertible proof. The Council is not judging a criminal case: there is no presumption of correctness in the original decision as there would be a presumption of innocence in a criminal defendant; and the objector need not prove their claims beyond a reasonable doubt, but rather to convince the Council that, in the best interests of the Web, their objection should overturn the decision. Still, it is imprudent for objectors or deciders to count on the Council doing their homework for them, as insufficient documentation can lead to the Council failing to see the point.
The Council is responsible for fully understanding all sides of the argument and making an informed decision. If the Council sees potential merit in the claims made on either side, but needs more information to be sure, it may investigate (or ask the Team to investigate) until its members know enough to responsibly decide. During this thorough analysis, the Council may learn new information, which might bear on the decision. But that new information should be incidental to the analysis—the responsibility to make a convincing objection remains on the objectors.
Placing the Burden of Convincing on the objectors is supported by several of the considerations above:
Speed. If the Council begins to look for additional new arguments, they are likely to take longer in their assessment.
Avoiding centralization. If every objection results in the Council accepting the Burden of Convincing on themselves, inevitably it will cause more stakeholders to bring topics to the Council and ultimately begin to centralize decisions.
Treating objectors consistently. If the Council begins to accept the Burden of Convincing on themselves for some Objections, then to be consistent, they will need to accept the burden for all objectors. That would be a tremendous expansion of scope for Formal Objections.
Workload. If the Council begins to accept the Burden of Convincing on themselves, that would considerably add workload to the Council.
The Council Decision Report section of the Process covers what information the Council is expected to provide in its report. Fundamentally, the Council needs to either:
Cleanly overrule the Objection and allow the Decision to stand.
Clearly sustain the Objection and require the responsible parties to address the objection.
Overruling a Formal Objection does not imply that there is zero validity to the Objection, only that the claims are insufficient to overturn this decision. To the extent that there is some validity to the claims of the objectors, a Council decision to overrule the Objection does not give the Decider authority to ignore these claims further in the development. It is therefore useful for the Council to distinguish between claims of the objector that they find to be without merit, and those that are merely insufficient to justify overturning the decision but are nonetheless legitimate concerns that should be investigated and potentially addressed later in the process.
When an Objection is sustained, the Council can suggest an approach that it believes could repair the Objection, but cannot make any dictates. The Council is not in the business of writing charters or technical reports; sustaining an Objection leaves the design of a new way forward to the responsible parties.
While providing guidance beyond a simple sustain/overrule decision increases the workload of the Council for an individual Objection, helping the community avoid predictable pitfalls reduces the amount of wasted effort both for the community and for future Councils.
Above we described, qualitatively, how the Council should deal with Objections. A useful Best Practices checklist may be arranged in categories.
The Team assignee and W3C Council members should be fully comfortable that they understand all sides of the argument. In particular, the Team assignees should not begin their resolution efforts before hearing and understanding the Objections (whether or not they agree with them). The W3C Council should not decide on the Objection until each participant feels they understand all sides of the argument.
The assignee and W3C Council should recognize that they have at their disposal any stakeholder who could reasonably inform the issue. This includes Working Groups, Chairs, Members, Team, and the general public. On technical issues the TAG might be particularly useful.
The assignee and Council should explore any potential paths to consensus that seem to have been overlooked. When consensus is not possible (at all, or in a reasonable amount of time), the assignee should at least understand and clearly document why.
Although the W3C Council's published decision should be clear, well explained, and unambiguous, it should nonetheless acknowledge legitimate points raised by the party that is not favored in the ruling, but explain why they are not decisive.
The Council will be fair to all parties not by attempting to excise all preconcieved opinions, but by bringing diverse, expert viewpoints to the debate and weighing them responsibly. The design of the Council therefore optimizes for the broadest engaged participation of its members, who represent the breadth and variety of expertise in the W3C community.
The assignee should inform all parties that potential resolution has been delegated to the assignee. In this same spirit, if the issue is referred to the W3C Council for decision, all parties must be notified. The report with the W3C Council's decision should include the names of the subset of the council that participated in that decision.
It is important for the assignee to offer all parties the opportunity to elaborate on their point of view. For example, although the Objection is already available in written form, the assignee should at least offer an opportunity to the objector to have a 1:1 conversation. All parties should be invited to key meetings where the assignee assesses whether a possible resolution proposal can gain consensus. If a decision goes to the W3C Council, all participants should see the assignee's report before it goes to the W3C Council.
The assignee and W3C Council should recognize that often Objections come from views of important Web stakeholders whose views might be under-represented where the decision is taken. Accordingly, the assignee and the W3C Council must consider all views.
Notwithstanding “Consideration of under-represented views”, the assignee and W3C Council should assign appropriate gravitas to a Working Group decision that was made by the consensus of the group and consistent with W3C Process.
Occasionally Formal Objections arise when a decision was made which did not follow the “letter” of the W3C Process. Such violations are quite serious and indeed could form a valid basis for a Formal Objection. However, the W3C Council is not required to always sustain such an objection—they need to take all factors into consideration in terms of the best solution for the Web.
W3C Council decisions form an important part of the public record; especially since they represent the most difficult areas in which stakeholders could not reach consensus and the Team could not resolve the impasse. Accordingly, it is important that W3C make available for the public record: the Team report, the W3C Council decision, and supporting documentation which explain the rationale of the W3C Council decision. (See W3C Council public records.)
The Council should clearly exhibit the qualities of fairness, transparency, and thoroughness described above. Depending on the nature, publicity, and degree of controversy of the Formal Objection, special effort may need to be made to explain how these best practices were achieved, e.g., to the public.
As the Formal Objection resolution process unfolds, all parties should be apprised of the status. There should be no ambiguity about who is responsible for the current step or what that next step is (e.g., the Team is writing a report, the Team is waiting for the Objector or Decider to respond to some question, the Council is being convened, the Council is in deliberations, etc.). The Council Team Contact should ensure that such communications take place and the process continues to move forward.
Feedback is to @w3c/tilt and is welcome on GitHub