Communication Tools
RUBRIC Project Communication Tools
The RUBRIC Project adopted a number of emerging technologies to manage communications in a dispersed environment, enabling the Partner Project Managers (PPMs) and RUBRIC Central staff to collaboratively work on documents together in a virtual collaborative space.
This case study explains the various tools used and benefits gained from Project members. For a more detailed study, refer to the paper Supporting Knowledge Creation - Using Wikis for Group Collaboration
Wiki
Wikipedia describes a wiki as:
computer software that allows users to easily create, edit and link web pages. Wikis are often used to create collaborative websites, power community websites, and are increasingly being installed by businesses to provide affordable and effective Intranets or for use in Knowledge Management
The RUBRIC wiki was established in the early days of the RUBRIC Project as a collaborative space to collect information on
meeting minutes
business plans
collaborative exploration of topics
record research on specific topics
partner knowledgebase
schedules
testing outcomes
conference and event information
“How to” guides
drafts of all documents under development
contact and leave details to track people's whereabouts
information about other projects
The type of content stored in the wiki was managed in different ways depending on the desired outcome.
Why is this a useful tool?
The wiki was useful in a number of ways. It enabled partners to share information and develop content collaboratively in a closed and trusted environment without worrying about particulars like grammatical expression or layout.
It enabled partners and the central team to pull information together into a single webspace, overcoming problems of network security that are associated with alternative solutions like shared drives.
It also incorporated the ability to include links directly to websites.
How did partners access the wiki?
The wiki software was set up on the RUBRIC servers at USQ and access was established for all staff involved with the Project at all of the organizations. A number of external groups asked for access occasionally and was consistently denied by the group.
The wiki was kept within a closed circle of contributors for a number of reasons. Firstly, it fostered a sense of trust: as the people involved in the project got to know each other they felt increasingly comfortable with contributing collaboratively to project topics. Secondly, people felt they could be uninhibited in their expression of ideas, knowing that their thoughts and contributions would not be vetted or viewed by anyone outside of the group.
What software was used?
The RUBRIC Project selected software called TRAC (http://trac.edgewall.org/) which gave the functionality of a wiki as well as a tracking system for work requests. All partners had the ability to create new work requests which were submitted to the RUBRIC Central Technical Team for action.
Work tickets could be linked into wiki discussion pages, such as minutes or agendas for meetings.
Use Cases
Case 1: Meeting Agendas and Minutes
RUBRIC Partner institutions engaged in a weekly teleconference call. The Agenda was loaded to the wiki a few days before the meeting and all partners were able to add agenda items or comments on agenda items prior to the meeting if necessary.
This made for organic planning of meetings: although they generally operated in a formal structure with regular agenda items such as “Business Arising” and “Site Reports”, any other business could be added for discussion by the Project Manager who wished to raise them. It meant that issues were not simply tabled at the meeting, but went onto the agenda as they were thought of inbetween the calls.
Minutes were created in real time by a nominated person at the meeting. One advantage of the software selected to run the wiki for the RUBRIC Project was the ability to link to “Tickets” which tracked work requests in the same system.
Tickets could be created on the fly and linked to the minutes during the meeting as work requests developed out of meeting discussions. This also meant that the progress on those work requests could be tracked automatically through the embedded link and would display as completed when the ticket was closed.
Case 2: Development of discussion topics by PPMs
At the outset of the RUBRIC Project it was agreed that it would be useful to collect the knowledge being uncovered and generated by the Project group and publish this in the form of a “Toolkit” that would be useful for other people going through the process of establishing a repository.
It was agreed that the wiki provided a good platform to collect this information because it could be added to and developed by any of the Project Partners. Each topic could grow organically depending on the particular interest of each partner at any stage of the process. As is typical of any large, dispersed project, partners were all dealing with different parts of the puzzle at different points in time and by using a collaborative tool to develop topic content they could all stay engaged with the process.
To start with, a Contents table was set up which grew to display 31 topics under discussion. Partners were free to establish a new topic of interest and add their thoughts and comments whenever they wanted to, or to edit comments inserted under other topics. Some topics grew rapidly, while others reflected individual interests of Project Managers. For example, the topic page on Copyright drew comments from four project members and covered information on:
other project outputs, particularly OAK Law
best practice guides
other university policies
practical suggestions and current workflows
a suggested position statement
digital theses and copyright issues
creative commons
rights management information
a link to del.icio.us bookmarks on the topic
The essence of these issues was distilled into the RUBRIC Toolkit section on Data Management at a later stage of the Project (see http://rubric.edu.au/packages/RUBRIC_Toolkit/docs/Data_Management.htm).
Wiki etiquette
In a collaborative workspace, it is important to have some guidelines in place so that people know what is expected of them and how to respect other contributors. The Guidelines for use of the RUBRIC wiki included
naming conventions for filenames
explanation of different types of pages and their respective use, such as software pages, partner pages
distinction between editorial practice on communal pages and editorial practice on individual partner spaces.
The following editing guidelines were stated:
Feel free to fix anything anywhere that is obviously broken like spelling errors and typos.
In pages that are communal you may do anything you like, including rewording.
In pages belonging to other people, you can, and should ask questions, seek clarifications etc, but do it like <sefton: What do you mean here?> - this shows that I am adding an annotation, using my login name.
Try to make as many links as you can, as you go.
Del.icio.us Community Bookmarking
All RUBRIC project members were given a basic overview of the use of community bookmarking to notify each other of useful websites located on topics of interest. See http://del.icio.us/about/
The benefit of community bookmarking is that you can keep all of your bookmarks in a central, web-based location which can be accessed from anywhere at anytime. Bookmarks can be shared seamlessly with colleagues.
Why is this a useful tool?
In a large, distributed project it is easy for the number of emails being managed to get out of hand, especially in the early days when project members enthusiastically contribute all items of interest to the group email address for consideration.
It also means that all of the sites identified by project members can be pulled up as a single group without further editing or tracking. From here, it is relatively simple to create a bibliography of further reading for all online material that has been flagged as being of interest.
Conditions of use
A few naming conventions were useful so that colleagues applied the same tags to pages that were of interest. This meant that issues on the same topic received the same tag, regardless of who had located the website and flagged it to be of interest.
Training
RUBRIC Central developed a procedure document initially which gave partners written instructions on how to set up their del.icio.us accounts and tag items of interest.
Incorporation into the wiki
Links to the relevant del.icio.us tag was inserted into topic areas of the wiki under discussion. For example, the Case Study above refers to a page on the wiki that collected information on Copyright and Rights Management. A link was inserted into the page to the tag “RUBRIC_Copyright” which listed all of the pages that had been flagged using that tag.
RUBRIC Project Communications Case Study October 2007
