Project Communication

As the project team were distributed across three countries, meetings were held primarily using telephone conferencing to reduce travel costs. These meetings were at least monthly.

Face to face meetings were held quarterly and additionally as necessary. JISC meetings were also exploited (e.g. programme meetings) as another chance to get members of the project team together.

The project maintained regular contact with the programme manager and supplied a number of informal updates. Members of the project attended all JISC programme meetings, and showed a poster at the meeting in Oxford.

Developers involved in the Shibboleth work attended a series of Shibboleth related events, including those organised by the Middleware Assisted Take-Up Unit (MATU).

Email

An email list was set up at Staffordshire University for email discussions within the project.

Ultimately, little use was made of the mailing list and project communication happened via standard email and the Wiki.

A project web site was set following standard JISC project practice but the project team also made use of a wiki for collaboration between the project team members.

A wiki is essentially a web site where the content can be easily and quickly edited by users. TWiki was used in the SUNIWE project.

The Twiki web site (http://twiki.org/) describes it as “a flexible, powerful, and easy to use enterprise wiki, enterprise collaboration platform and knowledge management system. It is a Structured Wiki, typically used to run a project development space, a document management system, a knowledge base, or any other groupware tool, on an intranet or on the internet. Web content can be created collaboratively by using just a browser.

TWiki looks and feels like a normal Intranet or Internet web site. However it also has a Edit link at the bottom of every topic (web page), everybody can change a topic or add content by just using a browser.”

Figure 1: The SUNIWE Wiki

The main benefit of the wiki compared to a traditional web site was that it enabled all of the project team to create and edit content. Files could also be uploaded easily and linked to from the text of the wiki pages to allow all project artefacts to be contextualised. This enabled the wiki to act as a central repository for project information, documents and files. Meeting minutes, the project plan, files used in development, outputs of the development process and discussions were all captured on the wiki. The email alerting facility of the wiki was configured to inform the project team when each topic had been updated so the team could keep up to date with the project information without wasted visits to the wiki site.

TWiki was chosen because it had a fine grained authentication and authorisation system allowing access to be configured for users down to the page level. This enabled the wiki to be set up for private use within the project team. The role of the wiki was different to the web site. The wiki was used for internal project communication and discussions. The project web site was used for dissemination of progress and outputs to the wider JISC community.

It was important to have a private project area to allow the team to communicate unhindered by consideration of a wider audience. A more public facing area would have stifled project discussions.

Although SUNIWE did not make use of it, the wiki could have been configured to have a separate public area which could act as the project web site. This would have been a good approach as the focus on the use of the wiki tended to leave the project web site neglected.

The wiki had disadvantages as well as benefits.

1. The structure of the wiki continually evolved during the project. As the content grew, long unwieldy pages or complex navigation often forced a restructuring. After each restructuring the project team would be greeted with an unfamiliar layout. This instability of structure was a barrier to effective use of the wiki.

2. The bulk of the content was created by one or two individuals. This was partly because of the unfamiliarity of the wiki concept. There was an understandable reluctance to restructure or change the content. This reduced the collaborative aspect of the wiki.

3. The securing of the wiki private area imposed a maintenance overhead. Accounts had to be created and managed and permissions configured on wiki areas.