By Jauco Noordzij

CLAAS Kickoff

Recently we had a kickoff meeting for the CLARIAH technical committee and the CLaaS infrastructure.

While the goal of the Technical Committee is well-defined:
"To develop interoperating standards that allow the software of the separate workpackages to interoperate", the approach to reach that goal is, ahh, not so well defined. Last week we came together to discuss how to achieve this goal.

Now, it is important to note that our goal can be considered a "wicked" problem, i.e. a problem that resists being tamed. Three important characteristics of these problems are that they have no definitive formulation, that there is no definitive solution (just a better or worse outcome) and also no ultimate test of a solution to the problem (you can't determine definitively if a solution worked).

It is also important to note that the technical committee consists of 11 people, each representing a group and each chosen explicitly for having a different view of the problem space.

Let's just say that we figured that a round-table discussion was not the  most effective method for formulating how to achieve our goal ;-)

Instead we used liberating structures to generate a common understanding of our goal and how to achieve it.  On the surface these are work-forms to facilitate discussions. For example, you might generate ideas using 1-2-4-all. As is often the case, the surface is the least interesting part though, and LS is mostly about finding ways to work together where everyone is engaged simultaneously, working in the same direction, and avoid getting "stuck" in writer's block or analysis paralysis. The community around these structures is continuously looking for micro-structures that enable us to interact in ways that are inclusive, easy to learn (aka expert-less), can operate on different scales, are fun without wasting your time (aka  seriously fun) and get you to someplace that's "good enough" for now,  allowing you to improve upon it when needed (aka failing forward).

In this meeting we answered a series of questions that bring you from a global purpose to concrete actionable steps without "locking" you into a specific solution (i.e. purpose to practice). It does so by posing 5 questions to guide your thoughts.

  1. Why is the work important to Researchers and Developers
  2. What rules must we obey to succeed in our goal
  3. What will we offer our clients/users/audience
  4. Who can make or break our goal

Each question is answered in a specific way: First we take a short time (2 minutes or so) where everyone thinks about the question and formulates their own answers. Then, you pair up with someone else and expand both your lists, again in a few minutes. Then two pairs form a foursome and exchange the items after which  filtering is done to select the top n items that the group considers most important (this is called 1-2-4-all). This method is similar to a distributed map-reduce job in efficiency and every time I used it, people have commented how efficient consensus was reached. You will usually notice both that (1) large parts of the individual lists overlap and (2) that the other group has some options that wouldn't have occurred to you even if you had had an hour to think about it.


While we have no definite answers to the questions yet, here's the current status

  1. Why is the work important to Researchers and Developers?
    • To increase interoperability and sustainability (that last one is also about keeping in manageable)
    • To enable to "unix philosophy" in research tooling
    • To keep IT standards in sync with research methods
    • To increase efficiency
    • To incorporate lessons learned and best practices
  2. What rules must we obey to succeed in our goal
    • Iterative (short experiments) co-design with both developers and researchers
    • Communication and documentation throughout the lifecycle
    • Keep a single (or very limited set of) communication channels
    • Use the MVP idea: set up the smallest possible standards
    • Be clear about the boundaries of our task. What are we not going to do?
  3. What will we offer our clients/users/audience
    • "Raw data"
    • Flexible repositories
    • Interoperable co-designed data + software
    • use cases
    • maintenance guidelines
    • API's
    • Libraries
    • existing tools + usage guidelines for research
  4. Who can make or break our goal
    Here, we noticed that we were unable to answer this question because it was not specific enough. We spent the rest of our workshop crafting a better question that we will answer next time:
    Who do we need to keep talking to in order to reach our goal?
    And for each person/group rate the along two axes
    1. To what extent can they make a decision that influences our success?
    2. To what extent can we learn from them

Lessons learned

  1. The success of the meeting is very much dependent on the quality of the question that you ask
  2. But if your question is not good enough you can make "what would be a better question" the next question
  3. The goal of these (or maybe any?) meetings is to create a common understanding across all participants.
  4. That trick where you raise your hand to get silence is really needed.
  5. Be explicit that you don't want to get it right the first time
  6. While the success of a meeting is dependent on the quality of the question, the smoothness of the meeting is dependent on the order and clarity in which you explain the workforms.
    • You can over-explain something
    • Always be clear when the explanation is done and people can start moving
    • Allow for questions before people start moving


We had a very positive kick-off session. I think it really set the stage  for people to start working on the CLaaS platform independently while still in collaboration.

We're failing forward gloriously :)