How to work together: Difference between revisions
No edit summary |
|||
Line 18: | Line 18: | ||
'''4. Create a workflow based on the baseline:''' Who are all collaborators involved? How much can everyone invest? Who is going to work on what? What is the time frame? What are in-between deadlines? Based on how much time everyone can spend, the deadlines and a detailed process plan can be formulated down to what needs to be accomplished every week. | '''4. Create a workflow based on the baseline:''' Who are all collaborators involved? How much can everyone invest? Who is going to work on what? What is the time frame? What are in-between deadlines? Based on how much time everyone can spend, the deadlines and a detailed process plan can be formulated down to what needs to be accomplished every week. | ||
'''5. Acknowledging and complimenting''' each others contributions to the process seems like an obvious step but is often forgotten during collaborative non-hierarchical processes. | '''5. Acknowledging and complimenting''' each others contributions to the process seems like an obvious step but is often forgotten during collaborative non-hierarchical processes. | ||
==Glossary of potentials for friction in collaborative processes:== | ==Glossary of potentials for friction in collaborative processes:== |
Revision as of 21:32, 25 October 2015
In your hands you are holding a collaboratively made publication. The content of this collaboratively made publication is also made collaboratively, mostly during the H&D Summer Academy 2015. We consciously introduced collaborative processes during the Summer Academy to stimulate different disciplines to engage with each other and to create a breeding ground for cross-disciplinary discourse. So it seemed natural to approach the documentation in a collaborative manner as well. Ultimately the nature of those two collaborative processes seem to differ remarkably. The content was produced during diverse 1 or 2-day workshops, in groups, which were assembled differently every day, in a total time period of 10 days. This publication containing the outcome of these collaborative processes was made afterwards, collaboratively as well, but during a longer period of time, without a strict end date, and with a more or less fixed group of collaborators.
I would like to reference a book, written and designed during a book spring at Transmediale in 2010. The book is about Collaborative Futures and the team of co-writers distincts between two different motives of collaboration. One is „the internal motive: curiosity, hunger for knowledge, the pleasure of participation or of belonging to something bigger than themselves.“ On the other hand there are „stimuli provided by the outside world: money, prestige, the promise of reward or the threat of punishment.“ Although all collaborators of this publication would probably, without hesitation subscribe to the first motive, the outside stimuli seem to inevitably sneak into the process if you are not situated in the ‚save bubble‘ of a cohesive summer academy program and obviously these external stimuli caused some friction during the process of making this documentation at times. Nevertheless we succeeded in creating a publication that is informed by technology as well as design thinking.
Since a documentation of the intense Summer Academy program was imminent we decided to use the chance and research new means of documenting and publishing ant the role technology can play in that. The question of new forms of documentation already arose during the Summer Academy itself. People experimented with Github and Etherpad for collective note taking during workshops and local networks created with Raspberry pi’s to share and exchange files. After the Summer Academy the ambition was to create an on- and offline publishing infrastructure, optimally using Open Source Software, and using this moment to challenge all before experienced editorial workflows and hopefully have an infrastructure for co-documenting ready by the time the next Summer Academy starts.
A number of steps that could be considered along the way of co-creating and publishing a documentation:
1. Critical consideration of the medium: What is the main goal of your documentation? Do you want to archive for the sake of evidence and completeness or do you rather want to create a reflected editorial work? In our case we decided that we would like to do both. The Wiki (See also: How to Document a Summer Academy) serves as the complete archive. Having gathered a variety of media, such as videos, sound files, images, short texts and bits of code as well as longer reads like transcriptions of lectures, we decided that we would like to show content both on- and offline.
2. A read threat: Coming up with a topic, ethos, concept, thematic agreement, or whatever you want to call a read threat, helps to tie the collaborative content production together. None of us is professional writer. Therefore we decided to write most text in the style of DIY manuals. That style didn’t have to be taken literally but served as a common intention in order to navigate and order the diverse content produced.
3. Create a collective process baseline: What are the challenges and interests that this investigation has to offer? What is everyones individual interest in creating this documentation, what does this process have to offer and how could all interests together be formulated into one common goal? We haven’t really defined that at the beginning of the process. Looking back it could have helped formulating an action plan together as a group and kick-off the process properly.
4. Create a workflow based on the baseline: Who are all collaborators involved? How much can everyone invest? Who is going to work on what? What is the time frame? What are in-between deadlines? Based on how much time everyone can spend, the deadlines and a detailed process plan can be formulated down to what needs to be accomplished every week.
5. Acknowledging and complimenting each others contributions to the process seems like an obvious step but is often forgotten during collaborative non-hierarchical processes.
Glossary of potentials for friction in collaborative processes:
1. Time-planning: Projects like this are often done with no or low budgets. Accordingly they tend to be postponed at times. It can lead to frustrations that collaborators have different priorities to different times, and have different external stress factors to deal with. In order to proceed with the project decisions sometimes have to be made even if not everyone is present. That can cause misunderstandings and eventually delay. 2. Cross-disciplinary vocabulary: The different languages everyone is speaking (international as well as interdisciplinary vocabulary) shouldn’t be under estimated. 3. Modes of production: Following up on the topic of interdisciplinary vocabulary, productivity is not necessarily considered productive in all disciplines. Marhall McLuhan said: „As new technologies come into play, people become less and less convinced of the importance of self expression.“ We experienced a highly practical definition of productivity versus a more discursive, conceptual definition of productivity. Some collaborators considered „talking“ as frustrating whereas others considered immediate ‚making’ such as programming or designing as overhasty as the concept isn’t straight yet. 4. Collaboration does not equal teamwork: There are different forms of working together. Some believe collaboration means every part of the process needs to shared. Others consider this idea of constant sharing of the process and working only in presence of the others as inefficient especially when it comes to complex matters such as hybrid publishing and also considering different disciplines work together of which themselves already. Not everyone can necessarily apply to those. Leaving enough space for individual thinkers without isolating them and at the same time creating the space for collective thinkers is the challenge here.
End notes:
As I previously mentioned that external stimuli can be leading motive for collaboration and that I suspect some of these extrinsic incentives to have slipped into our process and caused some irritations. However this glossary of potential frictions, was not added to warn or to call for avoiding these frictions. It is added to give a complete and realistic image of our process and even to to acknowledge these frictions. Instead of trying to overcome these frictions and stop them from interrupting the process I would like to promote the idea to accept and even embrace these unavoidable frictions and recognized their importance for cross-disciplinary and collective learning achievements. Accepting different ways of thinking and embracing opposing ideas and ways of working can be very inspiring and productive and carried on into future collaborations.
Resources:
- Collaborative Futures
- Hybrid Publishing Toolkit
- Beyond Social
- Post Digital Publishing
Thanks for advice: Andre Castro