en

Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

In addition to the U.N. six languages, this content is also available in

Public Comment - Summary/Analysis of Document Publication Operational Policy

Summary and analysis of public comments made to:

The Document Publication Operational Policy

[Go back to public comment October 2009 page]

Forum closed: 8 October 2009
Summary posted: 9 October 2009

Prepared by: ICANN general manager of public participation, Kieren McCarthy



BACKGROUND:

The Board approved a document deadline of 15 working days prior to an ICANN international public meeting. That means documents due to be reviewed and discussed at such a meeting should be supplied a minimum of 15 working days before its start so that people have sufficient time to read and digest their content before being expected to discuss them.

At the same time as the Board approved this approach, it asked the Board Public Participation Committee (PPC) to create an operational policy that covered other related aspects to document production, such as approach, translation, format and so on.

That policy was put out for public comment on 8 September for 30 days. It is worth noting that the comment period was also used to experiment with more interactive forum software than is the norm within ICANN’s public comment process. This summary/analysis will also consider the use of that software.

The PPC also held an online public session open to all community members to go through the policy and elicit further input. That session experimented with online conferencing software and this summary/analysis will also consider the use of that software (an archive of that meeting can be found at http://icann.na3.acrobat.com/p44978624/).


EXECUTIVE SUMMARY

The contents of the operational policy were universally applauded, notwithstanding a concern that the policy remain a series of guidelines rather than strict rules.

This is not surprising: most of the policy’s contents have been the subject of extensive discussion and agreement within the community for some time and the policy is simply a reflection of many hours of discussions and deliberations.

Nonetheless, there are some suggested additions to the policy that should be considered for inclusion before the policy is passed to the Board for adoption:

Executive Summaries

  • The inclusion of high-level options, as outlined in the document in question and where appropriate, to aid work progress
  • The recommendation that all summaries be translated into the UN languages

Plain Language

  • The inclusion of a process for promoting wider use of plain language e.g. training for frequent document writers; reference to free guides from the Plain English Campaign

Meeting agendas

  • The inclusion of a process for allowing community leaders to share information with respect to meeting agendas ahead of meetings

Translation

  • Stronger wording with respect to the timely provision of documents in other languages
  • Identifying executive summaries as one of the documents to be translated as a matter of course

Presentations

  • An expectation that presentations will focus on discussion rather than act as summaries of published documents
  • Recommendation that all presentations be archived in an easily searchable database

 

Software

This comment period was unique in that it experimented with two types of interactive software. First, vBulletin forum software was used for the public comment period itself; and second, the Board Public Participation Committee used Adobe Connect conferencing software to run a collaborative online discussion (as opposed to a one-way broadcast).

Both pieces of software performed beyond expectation and their wider use is encouraged across ICANN. The experiments were not sufficiently large and their use was not sufficiently broad to enable a firm recommendation for broad use. However, both served their functions extremely well, and were received as an improvement over existing systems. Others are encouraged to carry out their own experiments with both pieces of software and report back on their effectiveness and any lessons learnt from their use.

A fuller summary and analysis of the document publication operational policy and the software used within this comment period is provided below.

Back to top


SUMMARY/ANALYSIS

The Document Publication Operational Policy is a short and concise document, stretching to just four pages. Its intent is to provide a clear framework and guidelines for the consistent publication of work across the organization and so enable wide dialogue throughout the community.

It is broken out into eight different sections. Each section and feedback on that section will be considered below.

Document Deadline

The Board has approved a single deadline for international public meetings of 15 working days before the official opening of the meeting.
Working days are defined as weekdays, with a calendar week representing five working days. Public holidays are not treated as exceptions. The first day of the meeting is the one on which the opening ceremony is held.

The document deadline relates to the time at which the documentation is available for public review and download.

A poll was attached to this part of the policy. Two people voted in favour of the deadline; one against.

One comment was made which questioned whether the deadline would have a detrimental impact on the flow of work going through ICANN as much of the community remain volunteers. It also suggested the deadline may be a form of central control.

A formal response from the At Large Advisory Committee was appreciative of the deadline but was concerned it would create a critical time management point earlier in the process rather than tackle the bigger issue of more extensive planning and preparation of documents.

It is worth noting in terms of analysis that the deadline was originally requested by the Governmental Advisory Committee (GAC) in its Mexico City communiqué (March 2009). The idea of a deadline has since found almost unanimous support from the community and Board. The result of that process, for two ICANN international public meetings, has been the provision by staff of documents earlier that ever in ICANN’s 11-year history.

That is not to say the impact on volunteers has not been considered and will continue to be considered. One of the reasons for putting the publication policy out for public comment was to elicit community concerns. Staff will produce a report at the end of each meeting that reviews the efficacy of the policy.

Part of that report will inevitably review whether there is a net gain in the policy’s use and what, if any, issues arose from the imposition of the deadline.

 

Executive Summaries

Relevant documents should come with a cover sheet and an executive summary.

The cover sheet provides the most basic details of the document underneath, including title, source, status, publication date and language.

The executive summary is a short, concise summary of the document written in plain language. Jargon and acronyms should be kept to a minimum.

Such a summary should consider its intended audience and, ideally, briefly cover the environment the document exists within; the main details of the document; any conclusions or recommendations that the document comes to; and contain a “next steps” section to outline the path forward.

Examples of an executive summary and cover sheet are supplied in an appendix to this document to serve as a guide.

A poll was attached to this part of the policy. Two people voted in favour; none against.

One comment from the At Large Advisory Committee argued that the production of an executive summary in plain language and then translated was an essential step in encouraging participation and understanding. There were no other comments.

The limited response in the comment forum is quite probably because the issue of executive summaries has been one of frequent and widespread discussion within the community for some time. One of the key recommendations of the 18-month Improving Institutional Confidence consultation was also to provide executive summaries of documents.

Unanimous support for executive summaries has also been expressed at each of the PPC’s public session at ICANN international public meetings. The operational policy’s description of what should be in an executive summary was based on widespread best practice across many industries. In that sense, it is not surprising that there were few comments.

During the PPC online consultation session there was again widespread support for executive summaries. Several participants expressed a strong desire for translated versions of an executive summary.

One suggested addition to the summary, provided by a member of the PPC, was that an executive summary highlight the various options contained within a document (where appropriate) in order to help progress discussions.

 

Acronyms and Jargon

All acronyms and jargon should be spelt out or explained in the first instance. Where needed, a definition or link to a glossary for a relevant term or expression can be included.

A poll was attached to this part of the policy. Five people voted in favour; none against. There were one comment made by the At Large Advisory Committee in support of the section.

Again, the topic of acronyms and jargon has been one frequently discussed within the community and in PPC public sessions.

There is unanimous agreement that both should be kept to a minimum, and that agreement was reflected in the PPC consultative session where both community members and Committee members expressed frustration at the constant overuse of acronyms.

It was noted that a reduction in the use of acronyms and jargon (as well as plain language – see below) would aid translation of materials and hence increase understanding and participation across the organization.

 

Plain Language

The use of plain language is a condition for effective understanding and participation in ICANN’s work. Staff and community are expected to evaluate whether a document is written in sufficiently plain language before publication.

A poll was attached to this part of the policy. Five people voted in favour; one against.

There were three comments on this issue. All agreed with the guideline with one suggesting that a good guide to plain language be “simple enough that your mother would understand it”. The same consensus was reached during the PPC consultative session, with the additional point that some documents are difficult to understand even for native English speakers.

One concern was raised that the guideline may be used as a control mechanism to prevent publication of documents or to allow for censorship.

Since the operational policy specifically notes that it is designed to act as best practice and guidelines, it seems unlikely that the use of plain language could ever be an effective mechanism for preventing publication or allowing for censorship.

It is perhaps worth noting however that while everyone will agree with the use of plain language, the far bigger issue is how to ensure it happens. Sitting on its own a guideline is unlikely to have any impact on the production of documents. The guideline would have to act as a catalyst for other changes to be effective. As examples: allocating final production of documents to those recognized as being effective communicators in writing; producing simple guidelines for what is and is not regarded as plain language; training for those who will produce documents.

The Plain English Campaign, based in the UK, is internationally recognized as an expert in this sort of work and even provides a “crystal mark” for documents it assesses as being clearly written.

It offers training, both online and in-house, in writing in plain language, as well as free guides on its website at http://www.plainenglish.co.uk.

 

Meeting Agendas

The document deadline applies to meeting agendas.

Meeting agendas are defined as an overview of all public sessions taking place within the conference venue, both in the days before the official opening ceremony and after the final Board meeting.

That overview should include:

• a breakdown of topics to be discussed
• a list of speakers/panelists split up according to relevant subject
• an explanation of the session’s goals and expected outcomes
• hyperlinks to relevant documentation.

A poll was attached to this part of the policy. Two people voted in favour; one against.

One comment was made to this section. It argued that the section was useful as a guideline but since meetings vary widely, it should only remain a guideline rather than a rule.

Since the operational policy specifically identifies itself as a document encouraging best practice and guidelines, the commenter’s response has already been implicitly accepted.

Again, while everyone will agree with the idea of supplying meeting agendas, and while the format in the operational policy is a commonsense approach to providing such an agenda, the real issue remains how to ensure that it happens.

It is worth noting that five days after the formal document deadline for Seoul, in which all sessions are supposed to have been provided with meeting agendas, out of 75 sessions, only three provide information approximating to the guidelines above; 12 provide some detail such as panelist names; the remainder contain none or very limited information.

During the PPC consultation session, it was discussed that one of the problems with providing meeting agendas was that the system for deciding on meetings and their agendas was unclear as well as poorly communicated and coordinated across the organization.

 

Translation

ICANN has an adopted set of translation principles, found at: http://www.icann.org/en/accountability/frameworks-principles/community.htm#e

Those principles should be considered in the preparation of relevant documentation for ICANN international public meetings. In addition, this operational policy will be reviewed alongside those translation principles in an effort to find solutions to ongoing issues including:

• Which documents (or parts of documents) to translate, and into which languages
• The timely publication of translated texts
• Tools for multilingual discourse

Others issues to be considered include the measurable impact and cost effectiveness of translation efforts.

A poll was attached to this part of the policy. Three people voted in favour; none against.

There was one comment to the forum from the At Large Advisory Committee, which stated as a primary concern the timely provision of translated texts, and pointed to several previous formal statements on the matter.

The issue of translation was also actively discussed during the online PPC consultation session.

Again, the issue of providing translations of documents in a useful timeframe was raised.

While documents are published on deadline in English, a delay for other languages limits the time that non-English speakers have to review documents before they are expected to discuss them. It also restricts the ability of non-English speakers to interact with other community members at meetings on a particular issue.

The issue is compounded if there is a public comment period opened at the same time as a document’s publication, leaving non-English speakers with limited time to respond.

It was also noted that, under the new Affirmation of Commitments, ICANN is expected to internationalize and that translation will form a crucial part of that effort.

The issue of translating executive summaries (part of the operational policy – see above) was also seen as a valuable way of allowing the community to understand the work ICANN produces and so encourage wider participation.

There was also some discussion about the need to ensure that limited financial resources were used most appropriately with respect to translating text. Again, the translation of executive summaries was seen as an effective startpoint.

 

Presentations

Presentations should preferably be provided as far in advance of a meeting as possible.

A poll was attached to this part of the policy. Three people voted in favour; none against.

There were two comments made to this section. One argued that presentations at meetings should not be summaries of published papers but designed to elicit discussion of a paper i.e. the document deadline should provide with it an assumption that people have read the documents prior to a meeting about the document.

This point was also raised and supported during the online PPC consultation session. Limited time would be better spent discussing documents than going over summaries of already published documents.

The At Large Advisory Committee agreed with the early provision of presentations while also noting that as a largely volunteer organization, ICANN has to be prepared to see presentations later than desired. It also felt that more important than the early provision of presentations was to find a way to make them available in a searchable archive.

 

Reporting and Assessment

A report covering compliance with the document deadline and related operational policy, as well as the efficacy of both in enabling wider community dialogue and discussion, will be prepared by ICANN staff and provided to the Board Public Participation Committee within 45 days of the end of each international public meeting.

That report will help inform the Board Public Participation Committee’s monitoring of the document deadline, so that the PPC may then report back to the Board with suggested refinements.

A single control list of documentation to be issued for an international public meeting will be maintained, updated and made available online.

ICANN will work toward the introduction of a uniform naming convention for documents.

A poll was attached to this part of the policy. Three people voted in favour; none against.

The At Large Advisory Committee felt the reporting aspect was an important way to ensure the policy was reviewed and revised according to need.

The operational policy leaves the door open with regard to the format and contents of the staff report which has its advantages and disadvantages. Since the policy recognizes that it will progress and evolve over time, this section will no doubt receive more review once it has been be in practice for the first time.

Back to top


PUBLIC COMMENT PERIOD QUESTIONS

As well as the document itself, we asked three specific questions about the operational policy:

1. Is the community (and staff) prepared for the early provision of documents?

A poll was attached to this part of the policy. Two people voted in favour; two against.

The At Large Advisory Committee felt that the community would need a number of positive experiences before wider cultural change was possible but felt that the document publication operational policy was a good first step. There were no other specific comments.

The absence of broader discussion on the topic, considering its potential impact, would suggest that the community is not prepared and may not even be fully aware of what the publication policy seeks to achieve.

 

2. Are you sufficiently persuaded of the need for a document deadline to change established approaches and cultures?

A poll was attached to this part of the policy. Two people voted in favour; none against.

There was one comment that argued there are issues of greater importance to be tackled before a document deadline or operational policy, in particular general communications and transparency.

The commenter also expressed concern that the policy act as a barrier to the production of documents.

The At Large Advisory Committee said that, yes, it was persuaded of the need for deadline to change its culture and pointed to several elements in its Summit Declaration from the Mexico City meeting that demonstrated its thinking was in line with the operational policy.

As the PPC has recognized throughout the document deadline process, it is going to take time and active engagement with the community to sell the case for following a publication policy. A case needs to be made that outlines what benefits people can expect to see what changing their habits.

 

3. How do we effectively tackle the issue of language/jargon?

There were three responses online to this question. One felt that while the use of jargon is excessive, it is also common in technical fields and that it does not pose that great a barrier to participation, in the same way that mathematical symbols are universally recognized. Instead a focus on producing a glossary may be more effective.

There was tentative agreement with this point of view from the second commenter. They felt that when dealing with a range of languages and cultures (as ICANN needs to) there needs to be greater care taken in the production of documents, including the use of language and jargon.

The At Large Advisory Committee felt that the provision of glossaries was essential but noted that it would continue to be a challenge for some time into the future.

There is an intrinsic difficulty of course with those who are already heavily involved with ICANN ascertaining what aspects of their behaviour limits participation from others. It is a situation that will also not improved through ICANN public comment periods since that requires pre-existing participation within ICANN. Instead, the best guide will be to follow industry best practice and then actively seek the views of new participants as to what works and does not work with respect to the use of language and jargon.

 

OTHER ISSUES RAISED

Four commenters also expressed their strong preference for all reports submitted to the ICANN Board by staff to be made publicly available.

It was felt that the community has a right to know what staff is recommending to the Board, while acknowledging that there may be on occasion be privileged or confidential matters such as employee relations and legal analysis.

Two chairs of a Supporting Organization and an Advisory Committee concurred with this argument, one noting that providing any such reports would also enable the community to correct any wrong information contained within them.

Back to top


FORUM SOFTWARE REVIEW

As the second or two experiment with more interactive forum software, this comment period used the common vBulletin software.

Three comments were made in favour of the software, although one commenter was concerned that the experiment made represent use of even more software products and argued that ICANN should try to work with as few systems as possible.

From statistics taken from the software itself, the comment period proved far more popular that other comparative comment periods. Shortly after its introduction, the comment period saw 43 individual users reviewing the policy at the same time. In the end, 26 individuals registered with the software in order to post comments.

In total, the pages making up the comment period elicited 24 responses and 3,180 views. This is an above average results for an ICANN comment period, and significantly above average for a comment period that does not have a direct impact on contractual issues or result in structural changes within ICANN.

It is perhaps telling that no one used the traditional email-only method to send in comments to the forum, implying that people preferred the ability to respond to particular aspects of the policy and to be in a position to engage with others.

Many of the posts commented on others’ previous comments, adding an interactivity that proved valuable in every case (although there remains the risk that as the scale of this grows larger that moderation may be necessary to prevent argument breaking out, as is frequently seen on other online forums).

The forum software also enabled misconceptions to be cleared up by staff while the comment period was still progressing, which could well be expected to improve general communications and progression of work through the ICANN process.

The software proved to be flexible enough to respond to changes (the public comment questions were pulled out of one area and placed into another with no fuss and with positive results).

The At Large Advisory Committee was appreciative of the added interactivity provided by the software but also asked that the PPC continue to push for more research on and experimentation with participation tools while also aiming where possible to use open source tools.

Overall, the software proved itself extremely useful, increasing participation and interaction, encouraging discussion, and potentially allowing faster progress in the process of arriving at community agreement. However the software was not put through its paces sufficiently for it to be recommended as a replacement for the existing system at this point.

Its use should certainly be encouraged for comment periods in future as it possesses a number of useful features currently lacking in the current process, and there appear at this stage to be negligible downsides to providing this extra functionality.

Back to top


CONSULTATION SESSION SOFTWARE REVIEW

The PPC held an online consultative session specifically on the document publication operational policy using the conferencing software Adobe Connect.

Adobe Connect has been used extensively this year for conferences, but it has mostly been used as a one-way device to allow audio and video of events to be broadcast over the Internet, as well as presentations.

In this case, the software was used collaboratively as an open meeting with all the interaction going on online, including audio input (through people’s computers) as the main input mechanism. A chatroom was also used to share comments and react to others’ observations.

The session went better than expected, especially considering it was a first experiment.

The main difficulty was with respect to getting people’s computers to work through the software. A number of participants did not have microphones on their computers, making audio input impossible. Several others required helping setting up their microphone/audio feed. One Committee member was unable to get his system working.

The approach taken – essentially a chaired meeting but online – worked well but it did entail delays as people are required to actively “raise their hand” and then be selected to speak. This made the meeting less fluid than an in-person meeting but in the end this was a minor consideration and the meeting assumed its own pace.

The approach was certainly very popular with community participants. “This is one of the best meetings I ever participated remotely with ICANN,” said one. Another: “This is a nice tool. Very good meeting.” A third: “Thank you, excellent meeting.”

The At Large Advisory Committee was appreciative of the added interactivity provided by the software but also asked that the PPC continue to push for more research on and experimentation with participation tools while also aiming where possible to use open source tools.

In summary, despite concerns – especially with use of audio through the conferencing software – the software worked very effectively and provided an enticing form of interaction and some valuable feedback. In total, 24 people joined the session: 14 were community members, the remainder staff or Board.

Some guidelines would need to be drawn up for running such online meetings to improve their effectiveness but overall other committees and groups would be well advised to used the Adobe Connect software as a way of interacting with the community on substantive topics.

Back to top


ACTIVE COMMUNITY RESPONDENTS

ALAC – At Large Advisory Committee official response
JA – Jorge Amodio, ALAC
SB – Sebastien Bachollet, ALAC
AD – Avri Doria, GNSO chair
BF – Brett Fausett, Individual
CLO – Cheryl Langdon-Orr, ALAC chair
MN – Michele Neylon, Blacknight, Registrar
JN – Jeff Neuman, Neustar, Registry
DY - Danny Younger, Individual

Back to top