Notes on Efficient Internal Comunications Policy

Initial comment

This document was written up following the presentation at the EB meeting in Tübingen. It thus benefits from the discussion that followed the presentation. I will use green colour to indicate comments that i added afterwards in reflection on the points members of the EB raised at the meeting.


Work in CLARIN has not actually started in a big way, yet even the limited communication within the EB so far suggests that we should introduce some policy to ensure efficient and effective communication. As was rightly pointed out, most of the issues I raise concern exchanges of written communication within CLARIN. At the EB meeting the discussion also covered other channels most notably video conferencing but I will stick to my original agenda here.

In order to assess the workflow requirements we are facing, I'll first briefly review the acivities we will be engaged in as well as the actors and how they relate to each other. I'll then try to broadly define the functionalities that we definitely need and end with a suggestion for the kind of tool that should be used.


It is anticipated that among other things we will be

  • Organizing meetings, conferences etc.
  • Discussing documents, policies, strategies etc.
  • Drafting documents, minutes, policies, strategies
  • Monitoring progress
  • Collecting and archiving deliverables
  • Publishing reports, deliverables, FAQ
  • Interacting with users


CLARIN is a complex undertaking by a big consortium and an even wider community who will be asked to join the work in working groups. Participants are structured in a hierarchy that has the following levels

  • Coordinator
    • EB members (8)
      • Working groups (cc. 25)
        • partners
        • members

For each work package, there will be an average of at least three working groups consisting of the 32 partners (possibly one in several WGs), members, drawing from our community numbering cc. 90 and outside parties. We have to make sure that this complex network of people are adequately configured in the flow of information and everybody has access at the right level.

6.2.2008 KK: I suggest that we initially have two groups to handle the present KitWiki access:

  1. ClarinEbGroup as above, but including those persons who actively participate in the EB work, such as Lothar, Hanne, Martti, etc.
  2. ClarinGroup which includes the relevant staff of CLARIN partners and members of working groups but not people who are just members (and there would thus be just one group for all WGs)

The default write access and write access in the Clarin web would be ClarinGroup which includes ClarinEbGroup. I assume that they are all reasonable people, and the version control reveals anyway, if someone is not. Individual pages could have more restricted write access when appropriate.

The ClarinEbGroup would be used by default group for writing and reading for EB pages. Those pages which we wish to open for more public viewing, are individually marked so.


Reports, documents, deliverables etc. will typically span at least three levels, i.e. from working groups to Coordinator, before their content is finalized. If we want to carry on with the principle of maximum transparency that we have pledged to follow from the beginning and at the same time implement it efficiently with the inevitable time constraints among so many people then at each stage simultaneous collaborative editing will be required. Apart from the obvious lack of time to circulate documents several times, working with a single document that everyone (with the right competence) will have access to will ensure transparency and efficiency.


We need a content management system with the following facilities

  • flexible access control
  • simultaneous editing
  • version control
  • automatic notification of change (email alert/rss)
  • user friendly interface
  • customizable look (skins/templates)
  • customizable functionality (plugin modules)

Fortunately, there are lots and lots of free, open source tools available (e.g. PLONE, DRUPAL, TYPO3, TWIKI). TWiki, the system that we have started to use, courtesy of Kimmo, is far more than a wiki i.e. a collaborative web authoring system. True, its basic function is to serve as a wiki but through its numerous plugin modules it is capable of meeting all the requirements listed above

The human factor

It is clear - and the ensuing discussion made it abundantly clear - that this is an issue which cannot be decided on technical considerations alone. The attitute of the persons who are going to use the system must be held in utmost regard. In fact, acceptance by a clear majority is a critical criterion of any chance for success.

Evidently, what we are suggesting can only be successful if it is seen as not too imposing on engrained habits and the sacrifice of learnign to use new tools is clearly seen as such that is amply compensated by the benefits. Far from being dogmatic, we should adopt a solution that promises to gain the widest acceptance. (In this regard, I noted a palpable wish for wysiwyg editing methods, which I am confident will not be hard to meet.)

On the other hand, I think that devising a workflow that comes close to achieving the transparent and efficient collaboration that we want is a goal that we should all subsribe to even if it means we have to acquire new habits and exercise some discipline.


  • I am convinced that we have to adopt new methods and tools to make CLARIN-wide collaboration transparent and effective.
  • We should make ourselves less reliant on email, which have already proved a problem even at the current volume of traffic.
  • Instead we should increasingly shift our collaboraton to web based solutions
  • Wiki is just one of the functionalities we need. It's proper use concerns collaborative effort like collective editing of documents, exchanging views, conducting polls etc. i.e. wherever interacton is required. Reformatting MS Word documents by hand may not justify the effort required. With hindsight, I think we devoted more attention to this issue than it deserves because a) the process may well be automatized with macros and b) even the systematic archiving of the latest version of documents in a single site is already a huge advance over frantic efforts to drag them out from the depths of our inbox folders.
  • Technically, the tools mentioned above are capable of serving for internal and external use
  • Whether to merge them and under what platform is an issue that should be quickly but carefully investigated

To this end, Dan, Kimmo, Dieter amd myself will cooperate over the coming weeks and will make a recommendation to the EB at the video conference on 22nd February.

-- TamasVaradi - 03 Feb 2008

Topic revision: r2 - 2008-02-06 - KimmoKoskenniemi
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback