[Comments-evolving-multistakeholder-model-25apr19] Input into Evolving ICANN’s Multistakeholder Model

Mark W. Datysgeld mark at governanceprimer.com
Wed May 22 19:32:55 UTC 2019


Public comment for: Evolving ICANN’s Multistakeholder Model

This commentary was drafted by Mark W. Datysgeld, Internet Governance consultant and owner of Governance Primer, supported by the Brazilian members of the Business Constituency AR-TARC and the Brazilian Software Association (ABES). This group has for the past few years focused on advocating for better policies for SMEs and Global South actors, and these concerns underline this comment.

=Point A: Educational concerns=
To better argue this point, let us package together issues [3. Culture], [5. Demographics], [6. Recruitment], [16. Efficient Use of Resources] and [17. Volunteer Burnout], in order to discuss them under a single umbrella: Education.

This perspective comes from personally having gone through most of the engagement programs in ICANN, having later moved into coaching and selection committee roles for those very programs, as well as acting as an informal counselor and obstinate supporter of the NextGen selectees.

When a newcomer enters ICANN using funding from the organization, the number one priority has been for the longest time to explain to them the multiple groups and structures that compose the institution, with substantial resources directed towards this goal, including an increasing volume of material on the Learn platform. This is fair enough, as understanding the basic structure of ICANN and its workings can be daunting and take a significant amount of time.

However, once the person is considered to be acquainted with the basic workings of the system, they are more or less left to their own devices, and the responsibility is passed in an unspoken manner to SO/AC members that might be willing to voluntarily pick up the task of further educating the person in the policymaking process. This is an undocumented, completely per-case mechanic, which is certain to generate all sorts of gaps and disparities.

Self-education is not bad in concept, but there is a severe problem attached to the way this works in ICANN that limits effectiveness, which is that information about policy work is spread out, confusing, and at times misleading. Groups and initiatives change names and acronyms constantly (PTI and ODP are two recent examples, but certainly not the only ones), and a clear connection is not established between different incarnations of a project and related discussions.

Proper documentation and structured resources would be needed for people to be able to make this work well, but those do not seem to exist. Much of the PDP relies on understanding historical debates and building on top of previous processes, but this knowledge is usually locked away within the heads of veteran members, instead of being available in accessible webpages, where they should be.
The ICANN website is insufficient under whatever perspective you want to evaluate it. Finding information is difficult, and sometimes it's not even enough to know what you are specifically looking for. There is duplication of content everywhere, and a lack of proper hyperlinking. Let’s look at the very invitation to the webinar for this public comment:

* Page 1: “https://www.icann.org/news/announcement-2019-05-07-em” contains an invitation to the webinar and links to its two meetings, this is the page that got circulated to most community members, and therefore is the reference for anybody wanting to find out more about the activity.

* Page 2: “https://www.icann.org/resources/pages/governance-plan-improve-multistakeholder-model-2019-04-08-em” actually contains the material that would be relevant to whoever did not manage to attend the meetings, with the recordings and slide presentation available for download. The only reason most found out about this page was because it was cited on the webinar.

The link from Page 1 to Page 2 has the following text: “For a complete list of dial-in phone numbers for this webinar, please go to (link follows)”. This is, however, not what is contained in Page 2. Maybe at first it was, but then it was changed into the content of the webinar. For the person looking at Page 1, all they know is that they don’t want phone numbers for a webinar that is already finish, but rather slides and recordings. This kind of lack of attention is pervasive across the website and wastes a lot of time from volunteers. For somebody learning the system, it is appreciably worse.

Solution A-1: Structured training for newcomers that extends beyond the meeting they are first attending. Once a candidate shows interest in integrating the ICANN ecosystem, they need to be pulled into some sort of school, course, program, or whatever it is the community deems adequate. Anything that mitigates the current ad-hoc method of making new members effective is an improvement. This can be built into current engagement programs or integrated into the mission of SO/ACs, among other possibilities.

The Onboarding Program was an initiative that followed this premise, but was dropped due to not fulfilling expectations. I suggest that the expectations were wrong. The Onboarding groups were limited to very few hand-picked individuals, all of which had already found their way to an SO/AC, and acted more like a travel fund for promising prospects than anything else. That fund already more or less exists under the Fellowship program, so what would actually be necessary is a broader, more encompassing education program.

Solution A-2: The website reform is long overdue but always worth mentioning. It is not only a matter of making it prettier and clearer, but there is need for a paradigm shift in how information is organized and presented to community members. Pages about a theme need to be hubs for that theme, instead of a trail of crumbs that contain different pieces of the puzzle, requiring manual assembly that makes it into a chore for anybody who is not doing ICANN policy as their day job.

For example, the main page on Open Data should contain everything there is to know about it, all the news, webinars and historical information. The fact that this project started as a community initiative and that ICANN brought it into the org later on is already being lost to time. If a year down the road, a person suggests that it would be ideal that the project was done by the community instead of the org, is it unreasonable? Veteran members will shrug and roll eyes at the newbie comment, but isn’t it better if there was a decent way to research into such matters?

This can be achieved by various means, but systematic tagging and coding with intention to achieve this sort of structure are two relatively simple ways of going about it, in case the proper priority is given to the task.

=Point B: Structural concerns=
For this point, let us bundle a different set of issues: [2. Complexity], [3. Culture], [14. Trust], [18. Silos] and [20. Holistic view of ICANN]. These are closely related in the sense that they feed into the bigger theme of people not being able to relate to each other at a personal level, with it being commonplace to caricaturize those from other groups and pigeonhole their intentions in abstract ways.

The community usually thinks of these concerns as “silos”, but is that really so? It doesn’t seem to be only that SO/ACs end up stuck in their own heads, but more that there isn’t a forward-facing effort to get these different actors to actually understand each other; this only happens in an ad-hoc manner. This is not limited to the community only, either. From the org side, there is very little being shown about what the jobs of staff members actually look like. What is it that they work on every day?

To be fair, the Marby administration has helped this matter along, but interactions between the community and staff are often organized in a confrontational format, in which the community tries to one-up people from the org, and the people from the org try to keep their jobs. It can produce some results, but still won’t advance this concern towards a positive direction.

Solution B: Bridging the interests of different actors needs to stop being an aspiration, and actual measures need to be put in place to generate this. Just putting everyone in the same room for cocktails at the end of a working day at ICANN is not enough to generate this sort of interaction. There need to be activities that actually reinforce perspectives of actors as a solid group of people with the shared interest of making the Internet better.

It doesn’t need to be something bombastic. We need to highlight the contributions of individuals who are not in the spotlight better, and there isn’t currently a mechanism to help people understand what other community members are working on and how that may be valuable. ICANNWiki used to be one method to achieve that to some degree, but with the winding down of that project, nothing has emerged to replace it.

=Point C: Prioritization concerns=
Briefly, as far as issue [4. Prioritization of Work] is concerned, it is enough to say that it is quite confusing. The idea that it is the community that sets the priority of work seems misguided. What was the last time that a public call for priorities was made? Is it being voted? Is it being decided by consensus? Where and by whom? There are no clear signs of any of this, and everything that is known by people not on inner circles is made up of hearsay. A very clear push towards demystifying this is necessary.

Solution C: This is a matter that needs to be clarified, made crystal clear, because at this point it is anything but, and generic given answers such as that “the community” sets the priorities are quite insufficient. Point out who are the relevant actors, how are these conclusions being arrived at, and make it so that the path to being able to have input is widely known, even if that input is limited to chairs, councilors, or any other subgroup of volunteer.

=Specific suggested actions to be undertaken in relation to the current Issues=

A) Merge issues [5. Demographics] and [6. Recruitment] for discussion under the same framework.
B) Merge issues [7. Representativeness] and [8. Inclusivity] for discussion under the same framework.
C) Merge issues [12. Transparency] and [13. Costs] for discussion under the same framework.

Thank you for your attention.

May, 2019
--
Mark W. Datysgeld from Governance Primer [www.markwd.website]
Representing businesses in IG together with AR-TARC and ABES


More information about the Comments-evolving-multistakeholder-model-25apr19 mailing list