ICANN Blogs

Read ICANN Blogs to stay informed of the latest policymaking activities, regional events, and more.

Maximising the Community Wiki

8 June 2015
By Chris Gift

In addition to the ICANN Languages, this content is also available in

As I've said before in my blogs, the aim of the ICANN Digital Services team is to develop digital tools which will allow for better access to information and enable more efficient, and collaborative, working

As with all project teams, we're dealing with finite resources and therefore juggling priorities. On top of that, our working processes involve us looking at what's working and what's not, what's worth keeping and what could be improved upon or even discarded. So at the end of that juggling and reviewing, we may come across digital tools which are already functioning reasonably well and, perhaps, need evolution, not revolution.

Which brings me to ICANN's community wiki. Personally I find wikis a little awkward to use, a little clumsy. But it's not about what I like, it's about what works. If ICANN's community want to use a wiki and it functions for the purposes it was intended, then we shall make it so. Many of those that I, and others in the team, have spoken to see the wiki as a valuable tool, and one they would like to keep. Our job, in the light of that, is to make sure it works as well as it can, and to make sure we don't waste resources elsewhere by creating tools which replicate its functions.

The wiki is imperfect. We all have colleagues who have a messy desk that looks chaotic - but who can put their hand on the right document in an instant, because it's terrain they know so well it's intuitive. Don't take the analogy too personally but there's a number of user-types in the ICANN community for whom this is true - they use the wiki so often that the normal rules of usability don't apply.

My colleague, Steve Allison, did a report on the uses, strengths and weaknesses of the community wiki, which you can check out here.

The short version is that for many in the working groups, for example, it's a quick and dirty route to creating new content. They don't need to search the wiki for old content, it's already well-engrained with them. For others, there are quick, functional solutions they wish to access - they may need to poll a group of individuals for their consensus on a topic, or they may have a need to collect Statements of Interest before approving their admission. They just want a piece of functionality that can be built quickly and cheaply. It can be a bit rough, so long as it works. Or they may wish to seek out information and knowledge surrounding the topic of Internet Governance, and will see the wiki as a logical place to start. They want knowledge, not collaboration.

These groups may find a number of advantages in a wiki - that they can manage their own content and create their own pages - but that management by individuals means that there is no overall editorial control, which can lead to out-dated content and cluttered, badly functioning pages. Again, there's more in the report on this.

Within that, ICANN's role is unclear - does the organization have any level of editorial control over the webspaces of its community? In a community space, the ‘corporate presence' is difficult to get always right all of the time. ICANN is often the subject of debate, but not the source or the owner of that debate - and the utility of having ICANN staff using the wiki to provide content and join in the collaborative functions is tricky. I'm not sure what the answer is yet, so I'd be very interested in your comments.

So, while a community wiki performs a huge role in the range of digital services we wish to provide, there's much to think about and for us to do. We need to:

  • make sure the functionality is up to scratch
  • make sure we retain user data responsibly
  • Create an information architecture that is logical for all, rather than intuitive for the few
  • Devise an editorial process that makes sure content is up to date.

Some of those issues, content especially, could be eased by having more users - and that would be preferable to having the heavy hand of ICANN more closely involved. This is a community space, not an ICANN one, and it's important that we support improvements, rather than dash in and try and own it.

And that's just the basics - there could be much more ambitious plans to create a coherent content repository (see Steve's report for more), which offers a range of functions accessible to a wide range of the ICANN audience.

Done well, a wiki can be a valuable part of a range of collaborative tools and we think the wiki will survive some improvements. Quite how those are enacted we're still thinking on - we'd love your input, either directly to me (chris dot gift at icann.org), or in the comments below.

Authors

Chris Gift

Chris Gift