Introductory Text
By the Staff of ICANN
This Advisory was originally composed by ICANN Staff for the consideration of At-Large Summit Working Group 1 at their request, since the At-Large community has repeatedly suggested that the current public consultation process creates obstacles to effective advocacy on the part of At-Large. That original document is AL.SUM/WG1.01/INF.1.
In that text, At-Large Staff provided ideas on possible changes that could make the public consultation process more ‘user friendly,’ transparent, and accountable. These were based upon comments and suggestions made by members of the At-Large community over the course of time.
Subsequent to the Summit, the Chair of the ALAC requested that the Staff prepare a version of the original text in the form of a Draft Advisory of the ALAC. That version of the document was made available to the ALAC Executive Committee on 19th May 2009 by the Staff.
End of Introduction
The At-Large Advisory Committee recognises that ensuring that processes designed for enabling the participation of those concerned with the policies that are adopted by ICANN are a foundation of the bottom-up based, stakeholder driven model that ICANN is intended to exemplify. At the core of these processes is that by which public comments are solicited and what results from those comments.
At its heart, the existing public comment process is little-changed over the last several years, whilst at the same time the community itself has changed considerably. We note that there have been some positive developments – posting summaries of comments received has become routine, for example, which is welcomed, however this is not enough. We believe that the time is ripe to improve various fundamental aspects of the process.
Concerns Related to the Present Process
The ALAC has a number of concerns about public consultations:
1. There appear to be limited, or no, rules related to:
a. Who may initiate a consultation;
b. When a consultation may be initiated;
c. What issues or subjects require consultation and which do not (except certain bylaw-regulated consultations);
d. How long a consultation will last (except certain bylaw-regulated consultations);
e. What information must accompany a consultation to provide context;
f. What languages a consultation shall take place in;
g. When a consultation may start;
h. What level of participation from the community equals a reasonable level of consultation to proceed to the next stage in the work process; and
i. For a consultation that is related to an evolving document, there is rarely a document history showing the changes between the versions under consultation. This then requires those who have read a document for a previous consultation to re-read the entire text to try and find the differences.
2. Those starting consultations are not obliged to think about the following in advance of starting a consultation:
a. Are there many other consultations already taking place, or not;
b. Are there any stakeholder communities who will require educational materials or briefings in order to make informed comments;
c. What amount of input from the community overall is sufficient to proceed to the next stage in the process being consulted about;
d. Are there any particular stakeholder communities that the consultation is particularly relevant to - if so, are the communications related to the consultation correctly targeted to solicit input from that community or those communities;
e. Are the messages in the consultation easy to understand; and
f. Should any advance notice of an upcoming important consultation be transmitted to the staff or the stakeholder communities?
3. Information is not maintained and made available in an organised way across all consultations with respect to:
a. What consultations are upcoming, and when;
b. How many participants each consultation has had; and
c. What kinds of participation each consultation has had (e.g. what different communities have responded).
4. Those who respond to public consultations rarely see any feedback on what effect their responses had:
a. Consultation input is summarised in the summary of comments posted, but the next steps in the process rarely provide any clear link between a comment and whether or not it was reflected at the next stage of the process;
b. The summary of consultations is not communicated directly to all those who responded, or to all of the relevant stakeholder communities, so they may not be aware of whether or not their comment received any notice;
c. Responses by Advisory Committees or Supporting Organisations to the Board of Directors are not routinely acknowledged, nor does the community see evidence that the Board routinely discusses these statements, or what direct impact they have on Board decisions.
Impacts Related to the Concerns Above
We note the following important impacts of the above:
- With few exceptions, the community has no advance notice of consultations. Only those integral to developing a consultation’s materials are likely to be aware that one is coming on a given subject.
- Without advance notice, the volunteer community cannot readily plan its time or program its workload in responding to ICANN issues;
- The whole community usually only knows a consultation has started when it appears on the public website (with the exception of advance notice provided in the monthly Policy Updates), and no background information on the consultation beyond what is publicly posted is available (or if available is often difficult to find);
- The time allotted for most consultations and the lack of advance notice means that if any briefings are needed to help educate parts of the community these must be arranged in a rush, if at all; little to no advance planning is possible;
- Consultations often begin immediately before an ICANN meeting, and/or often end shortly after the ICANN meeting ends – at the precise time when Staff and volunteers are preparing for the meeting and have limited time available to read, discuss, and decide what to say on a consultation;
- For consultations on evolving documents, document history showing the changes between the versions is not provided, requiring those who have read a document for a previous consultation to re-read the entire text to try and find the differences;
- Community members who attend ICANN meetings have a much greater ability to influence a process or outcome than those who are not, and the same is true for those who try to participate remotely. Those attending meetings are able to learn via workshops about the objects of consultations, and those not able to attend are disadvantaged;
- Important consultations receive less attention (as volunteers cannot devote full-time to ICANN, especially before a meeting – they have to finish their ‘real’ work to take time to attend the meeting – and after the meeting is over, they have to return to work and have less time to spend on their volunteer ICANN activities for some time after returning home);
- Communities that have greater resources to devote to consultations arguably have more ability to influence outcomes; and
- There is generally not enough time to arrange translations so any community that cannot speak, read, and write fluent English is highly disadvantaged.
Changes to Make
The ALAC suggests the following changes to the consultation process:
1. Create and assign Staff to maintain a public calendar where all upcoming consultations are to be posted in advance, showing:
a. What ICANN body or department is requiring the consultation;
b. What, in brief, it is expected to cover;
c. Why it is necessary;
d. What are the related processes, and their timing;
e. What languages the consultation is proposed to take place in;
f. What documents will need to accompany the consultation and where these can be found.
This should be kept up-to-date as the start date of the consultation draws nearer. Any consultation not in the calendar at least 1 month in advance of its start date may not be launched without explicit Board assent.
2. Not less than 45 days before a consultation begins, an announcement on a special section of icann.org shall be posted, which shall provide the following basic information:
a. A short and easily understandable title;
b. A short description of what will be covered;
c. When it will start and how long it will last – and if there’s any uncertainty about these facts this would be made clear;
d. Why it is being originated;
e. Who is originating it – both staff person responsible and ICANN body/process, as relevant;
f. What the previous step is/was in the process and what the next steps will be;
g. What if any reference documents will accompany the consultation, and where those may be found.
h. For a consultation on an evolving document:
i. A link to a redlined version of the text showing the changes between consultations must be posted so that it is easy to see what has changed between the previous text and the present version;
ii. A brief narrative summary of the changes between versions linked to the consultation announcement.
i. What if any other information may be found to provide further information for those new to the issue in question.
j. What languages the consultation will take place in.
k. Whether or not the Board of Directors is particularly seeking AC or SO comments on the consultation (if known).
This new section should be integrated with the current main public consultation pages for ease of review. It should also be RSS feed enabled. Links to it should exist prominently on all microsites of icann.org.
3. Not less than 30 days before the consultation is to begin, all documents related to it must be available and in the requisite language versions. Consultation ‘clocks’ may not start unless a document has been publicly available for 30 days without specific Board assent to the contrary.
4. ICANN Management should use the calendar to ‘program’ the consultations throughout the year. The objective should be to ensure that consultations are, to the extent possible, spread out over time – and wherever possible to ensure that very important consultations are not concentrated during short periods of time – especially before and after meetings.
5. Stakeholders who believe there is a need for translations in languages other than those proposed in step 2 are required to provide this information (and the reasons for it) to the originator of the consultation not less than 45 days before the consultation begins.
6. To the maximum extent possible, consultations should have a consistent duration – not less than 30 days.
7. If a consultation will be on a technical or other issue which is likely to require some members of the community to receive further information in order to provide informed input, the responsible Staff must notify relevant stakeholder groups not less than 30 days in advance of the start of the consultation so that briefings can be arranged if needed.
8. The concerns identified in the section above entitled “Concerns Related to the Present Process” should be addressed where a solution is not specifically recommended.
The ALAC understands that the changes we’ve proposed are profound. We believe that they would greatly improve the process for all stakeholders, not just At-Large. We would further suggest that they would greatly enhance the accountability of ICANN, and would also lead to more, and more informed and useful, public comments.
