Methodology for ICANN consensus-based reports
[ cf. http://www.dnso.org/wgroups/wg-d/Arc00/msg00414.html ] [ HTML edition from the above message ] [ written by David Johnson, posted to the WG-D on 13 Sep 1999 ]
Don Telage spoke at the Names Council meeting about the importance of defining a clear goal for the working groups to shoot for, perhaps in the form of a template for the kind of report that should accompany any recommendation for forwarding a consensus proposal to the Board.
Brett Faucett has reposted a prior short list of some of the elements of such a report -- and requested additional suggestions and comments.
The following is a somewhat expanded list/template, designed to reflect lessons from our first experience with the Working Group A report and the resulting ICANN staff report, as well as useful comments from David Post and others regarding the nature of consensus. The interspersed explanations are designed to discuss reasons for particular elements and procedural implications of certain requirements.
I would suggest that Working Group D might submit such a template because it could help to define and channel the work of other working groups and provide a basis for careful review of any Working Group work product by the Names Council and the Board.
Obviously, the early and intermediate work products would not need to aspire to this level of completeness. I think working group chairs should explore ways to form subgroups to tackle particular subsets of the work -- articulating alternative proposals, assessing likely impacts, summarizing key points raised by various stakeholders, outreach, etc. The long list that follows is an attempt to flesh out an ideal end product of that fragmented, intermediate work, sort of a checklist for use by working group chairs as they assess the prospects of coming to a recommendation and report that really does have consensus support.
Discussions on the lists pose the risk that every comment might be understood by the poster or others to represent an effort of formulate a consensus proposition. We need to focus discussion on a finite number of proposals. Obviously, the early stages of a working group process might generate a number of competing proposals. A search for support and endorsements will help to sort of those proposals (and combinations) most likely to lead to consensus.
A report claiming consensus should explain why the proposal should take the form of a uniform policy. Those who have not been deeply involved in the working group will be enabled to evaluate the proposal against the background of a stated goal -- and this could lead to suggestions on better ways to reach the stated goal(s).
No one could evaluate the claim that consensus exists without knowing what meetings have been held, with whom, and what steps have been taken to contact potentially impacted parties. The more extensive the record of the process, the more convincing the case will be that dissenters have had their views adequately taken into account. The less extensive the process, the more credible claims by those who still object that a consensus has not been reached.
It is fair and relevant to point out that other non-ICANN processes have extensively considered various issues. Prior deliberation doesn't necessarily support an artificial declaration of consensus -- but it can help to frame the issues and to put various statements of support and opposition into better perspective.
Working groups are open, of course, so there is no requirement for particular qualifications -- nor any disqualification based on affiliation or prior statements of position. The Bylaws contemplate that experts may be consulted and invited -- and a statement of their qualifications can help to give their views weight. The most active participants in the process of formulating any particular draft ought also to be fully described -- so any reader can evaluate potential sources of bias.
It is highly unrealistic to expect that any "working group" will include all of the parties that might be impacted by a proposal or whose views need, somehow, to be assessed. Accordingly, outreach is essential. We have many channels for outreach -- and even failure of some impacted parties to respond to email and calls would itself yield valuable evidence of the extent of interest, support or opposition. While proposals should be placed on the web for public comment, that step alone will likely only reach those already engaged in the process. A thoughtful working group will go out of its way to make an extensive record of affirmative outreach -- and will be able more strongly to claim consensus if such a process does not turn up strong dissent.
To make a complete record, the working group should document the fact that its deliberations were fully disclosed and publicly announced. Every drafting subgroup should not have to proceed in public, of course. It may be that substantial advances towards consensus can be achieved in private conversations or even in the efforts of a single individual sitting down to write out a new proposal or explanation. But the overall flow of discussions should be kept open for input -- and the report of a working group that claims to have achieved consensus should be able to explain how this was accomplished.
The greatest uncertainty about any proposal, from the perspective of those not intimately involved in its development, will be the extent and nature of its impacts. An effort to analyze the nature and extent of impacts will show that the proponents have extended their thinking to cover all points of view -- and it will help potential supporters and opponents to decide when to speak and consider how to develop alternative proposals that minimize negative impacts and maximize positive ones.
Once impacts have been surveyed, it will be easier to go down the checklist of potentially impacted parties and demonstrate, concretely, that their views have been heard or reliably assessed.
The actual text of discussions among a working group may be quite extensive. To allow neutral assessment of the result, the substantive content of the discussion must be summarized in a coherent way. This process will require a relatively fair and neutral scribe -- the presence of whom will itself help to generate a trustworthy report.
The key question posed in any consensus-based process is whether opposing views (of which there will always be some) are isolated, limited in intensity, shared only by those with low stakes in the process, or unreasoned. For this reason, it is critical that a report specifically analyze the substance of opposing views and point out the best answers to those views or otherwise analyze why the opposition should not be entitled to enough weight to allow the conclusion that consensus has not been reached.
It is not enough to focus on substantive analysis. Rather, a consensus report should analyze the distribution of views among parties. Such an analysis may have to look at the affiliations between parties, the relationship between substantive views and stakeholder interests, and any patterns in coalitions that might shed light on where further improvements or compromises are most likely to be found.
If a proposal imposes a disproportionate burden or implementation duty on particular types of parties, any opposition from such parties would be entitled to greater weight in evaluating the presence of consensus. It is all too easy for those who do not bear the costs of a proposal to support the imposition of those costs on others. As an analogy, the "takings clause" of the US Constitution recognizes that it is unfair for one or a small group of parties to be singled out to bear the costs even of government actions that all agree would serve the general interest. A thorough working group report should pay special attention to the views of any groups on which the costs of a proposal will disproportionately fall.
A working group report should be designed to reach a broader public. It should educate the less informed.
A key section of the report should expressly address the claim to consensus -- describing concrete reasons to believe that affirmative support is widespread. This is in contrast to the mere claim that an internal working group (or Names Council) vote has been taken and has produced a majority or even supermajority. The legitimacy of ICANN will rest on demonstration that its policies are actually supported in the real world, not just that its active participants have agreed on some proposition.
The corrollary of the foregoing is that the report will show that opposition should be disregarded, for specific reasons that go to the relatively low intensity of the opposition, the source of the opposition, and the unreasoned character of the opposition. In addition to analyzing the opposition, the report should analyze the affirmative reasons to disregard it.
For completeness, and to avoid later questions, the report should document or cite to those organizational documents that show ICANN is competent to address the subject matter of the proposal. In the early stages, specific reference to sections of the White Paper and ICANN's MOU would help to provide support to a proposal.
Since the alternative to a consensus proposal is always decentralized decision-making in the marketplace, a thorough report should analyze this alternative and show the nature and extent of any need for a uniform policy.
ICANN doesn't not exist in a vacuum. Where policies implicate legal issues, the relationships should be explained.
The meaningfulness of consensus for a policy will differ depending on whether and how extensively it is likely to be implemented. ICANN will likely rely on contracts to require implementation. The relationship of the proposal to such contractual obligations should be analyzed. The report should also analyze the relationship between the proposal and any existing contractual obligations of ICANN and any previously adopted policies.
To reiterate, I'm not suggesting that any proposal must cover all these bases or that all intermediate drafting should take this form. But the productivity of working groups might be improved by a shared understanding of the ideal outcome. At a minimum, this kind of checklist would help the chairs assign specific tasks -- and allow the chairs to respond to discord by challenging participants to come up with drafts for particular subsections of a final report.
||© DNSO WG-D