Collaboration

From Organic Design wiki
Revision as of 00:45, 5 December 2007 by Nad (talk | contribs) (Turn taking)

In the wiki environment, collaboration is a term which comes up often in conversation, but what exactly does it mean in the wiki context? After using the wiki for a couple of years there have been a lot of examples of a group of two or more of us collaborating on certain creative endeavours, some of them have gone well and lead to completion, some have got off to a good start, and yet others have failed to get off the ground at all.

The technical aspects if an efficient collaboration system have been defined and are slowly being implemented in the form of wiki extensions such as the workflow extension. Further down the track we intend to develop these ideas into a more ideal structure within the nodal environment.

Aside from these developments, I think it's important to address some more fundamental aspects of collaboration which would be part of the MediaWiki Workshop and of other documents such as charter, manifesto, help and best practices. These aspects of collaboration are described in the following sections.

Shared vision and responsibility

Define shared vision and expectations: this needs to be done regardless of scale. It could be a simple document or trivial programming excercise, or it could be an entire application. Either way the collaborators must have clearly defined what they all expect from the result to be and what parts they're each playing in achieving this.

An important point to note when it comes to defining shared vision is that it must be defined in terms of the roles and processes available otherwise there is no path available to the organisation that can lead to the vision.

Another important issue with shared vision is diversity. In the book The fifth discipline the concept of an organisation's ability to "harmonise diversity" is introduced (on page 228). In the context of collaborative systems this ability translates as analysing the commonality of the diverse views of the shared visions and "forking" smaller groups which work together on sub-visions which are defined from the differences they have to the master vision. The original group of all members continue to collaborate on the aspects which are shared amongst all visions.

Turn taking

Of course one major phase of collaborating on anything is the actual day-to-day chipping away of the work, but there's an important aspect of this which needs to be made explicit and in many cases would even benefit from being formalised with categorisation. It is the concept of turn taking which describes the aspect of conversation whereby only one person talks at a time and the focus (the person currently talking) changes from person to person (for more detail about this concept see conversation analysis).

The wiki environment is not a normal free-flowing conversation, but rather is a blackboard system where the focus moves amongst the roles working on a thread of work (such as an article or some code). Each work session performed by a role involves becoming familiar with the state which has changed since the last time they worked on it, and then using their expertise to refine any aspects which now need attention. After doing this the role will either consider the job to be complete and notify the other team members, or will see that further feedback from other members is required. Categorisation and workflow tools can aid in the organisation of notifying members that their feedback is required.

It's important for all members to be very clear about this aspect of collaboration, because I've found this to be one of the main ways in which stagnation occurs. For example, I'm sure every seasoned wiki user is familiar with the feeling of talking with friends or colleagues about an idea they all share a common interest in, and then deciding together to start an article outlining the goals clearly so they can begin working together on it only to find that after one or two edits it completely stagnates never to move again. I believe a major reason for this common occurrence is that one or more of the members don't realise an unspoken fact: it's their turn to apply their expertise. If they were all working with the turn-taking context in mind they'd see from their watch-list, or from the changes that some significant work had been done over some time period and would realise the expectation that a different member must now commit time to a session of work on it for it to progress and to fuel the collaborative effort and keep it rolling. If there's many threads under way then todo lists and categorisation cat easily be employed to avoid forgetting which threads of work are in need of a particular role's attention.