Collaborative Technologies

During the Phoenix WGM (January 2006) a "Wiki Nite" was organized as one of the "open space" meetings during the WGM. The aim was to raise awareness of Wiki technology (and other collaborative technologies) to support the process of creating HL7 standards.

Wiki

A Wiki is a good tool for the editing of "dynamic" documents as part of a collaborative process.

How Wikis support a TC/SIG or collaborations between TC/SIGs:

1. Consensus process for an issue. A highly contentious issue (lots of e-mail traffic on the lists) can be halted after initial discussion. The HL7 listserves occasionally erupt into lengthy back-and-forth discussions that have diminishing information value to the majority of list-readers. If there was a better mechanism to move those discussions to a more focused venue, many people would be grateful. A summary can be posted to the Wiki, for all partcipants to edit, until a consesus version has been reached. This is one of the possible benefits of a Wiki to HL7: it reduces traffic on listserves. Once consesnus has been reached, the contents of the page can be frozen, and the content can be included in a ballot.
2. Glossary items
3. Harmonisation Proposals. Use the Wiki to publish the proposal, use it to colect comments during a public comment period prior to the harmonization meeting. Update with discussion + harmonisation result during the harmonisation meeting (i.e. supports the harmonisation meeting itself as well). This provides real-time feedback to all as of the latest status and outcomes of the harmonisation proposal.
4. Agenda (e.g. for a WGM)
5. Meeting minutes. The meeting minutes can be created during the meeting and saved every few minutes. That way all participants are able to review the minutes and make suggestions as to improvements during the call/meeting. A few days after the meeting (when all cortrections have been made) the contents of the page can be frozen.
6. Action item list
7. During a WGM: for each TC/SIG, post (on a daily basis) a summary of issues that were discussed and that may have an impact on other comittees. Or: highlights in general.

What should probably NOT be on the Wiki:

1. Fixed artefacts - this is better left to a document repository (or HL7 website), with version control mechanisms. ANSI requires that minutes and artefacts be available to all (the HL7 website is better suited for this than the Wiki).

Various Wiki Notes

• There are various offerings of Wiki-software, some of which allow enhancements to the original Wiki concept by providing modules that allow the "freezing" of the content of a page, or agenda functionality to monitor action items.
• There is another potential tool called TWiki that the Department of Informatics at Mayo has been exploring that addresses the management of document evolution, scheduling, resolution tracking, etc. Mayo is doing a comparison between the current Wiki and Twiki to determine what the differences in functionality are, and is looking at how to import the existing wiki content into a TWiki. For example, Twiki has a better agenda function that the current Wiki.
• It is a good idea to create Template Pages that can be used (copied) as a starting structure, to be filled in by those that use the template. Example template: meeting minutes, agenda.
• There is a MS-Word macro to transform Word documents into Wiki documents (Wiki uses a very simple markup language, but some transformation is needed)

Organizational issues

• Management of the Wiki: who will take responsibility for vetting the information placed in the HL7 Wiki? What should the HL7 Wiki Etiquette look like ?
  • One of the nice aspects of a Wiki site is the opportunity to have free exchange of thoughts. The challenge is that changes are made more easily and is therefore subject to proper wiki etiquette and discipline, as well as that at any point in time the site may not be reflective of the collective consensus on a particular topic. Simple Wiki etiquette requires that contributors stick to facts and consensus on the main pages. The comments/talk/discussion pages are for anything that is questionable, controversial, or unsettled. Wiki Moderators need a effective way of discouraging heated open disputes.
  • The option of "freezing" of pages (a lockout) should probably be limited to co-cahirs.
• Do we need a Wiki that is maintained/controlled/administered by HL7.org, and if so, how do we arrange this?
  • A knowledgeable team is needed to manage/update the Wiki software. Mayo is willing to host the HL7 Wiki until such a time that HL7 decides to host it, and provided that use of (human) resources is limited.
• Normative status of the Wiki content. A combination of a wiki site and a web site, one flowing freely and openly knowing that it is such a dynamic site, the other controlled and reflective of agreed to direction and "sanctioned" materials, suits the combined needs. In a way the wiki is no more sanctioned then the cumulative list server activity, but easier to get the bigger picture of a discussion. Once consensus has been reached on the Wiki, the content can be frozen and included in a ballot.

gForge

gForge is probably best known as the software used by sourceforge website. It has all kinds of features that support software development (version control, issue tracking, etc.). It is currently used by the Tooling comittee to support the development process of software.

Wikis and gForge are complimentary rather than conflicting. GForge allows tracking logs and fixed documents. Wiki allows dynamic documents. The support for the tracking of Action Items is better in gForge.

Skype/IRC

Technoligies like Skype/IRC are especially used during WGMs for "cross-comittee consultantions". The parties involved are taking part in committee meetings of separate committees, but are able to briefly consult a domain-expert which is in another meeting.