collaborative work / collective work
Tools shape practice shape tools...
Under what conditions do you collaborate?
Who is part of the "collective"?
Who has the power to make decisions?
from IPython.display import IFrame IFrame("https://ecotones.caveat.be/osp.html", 1200, 600)
OSP's collaboration agreement
Versioning is a method for dealing with divergence in networked collaborations. While originally developed to track software production, it is implemented in Wikis, etherpads and other digital writing tools. Log files and so-called “diffs” are automatically saved to make the incremental process of shared editing transparent, or at least to machines, since any action can be reversed or repeated at any time; errors or unwanted inputs can be later corrected. Even if the conventional narrative of “versioning” is one of streamlining collaboration and producing consensus, these techniques and technologies do pay attention to difference.
Conversation, discussion, collective decision making, task lists... these are all very useful tools for collaborative work.
Git is a a collaboration tool mostly used by programmers to work together on code.
Git is free and open source software, published under a GPL 2.0 license which means that it can be used, studies, modified and redistributed under the condition that it is published under the same or similar license.
Git is created by Linus Torvalds in 2005 as part of making the Linux kernal.
git != github != gitlab != gitea
You probably have heard of GitHub, a popular implementation of git that is used by many developers to share their code. It was bought by Microsoft in 2018. GitHub is not the same kind of software as git is. GitHub and GitLab and Gitea (the one we use at XPUB) are web interface software projects that allows you to work with git through the browser. Git, on the other hand, is the underlying software that is used by these projects.
Git comes with a whole set of collaboration tools build in, such as:
The web interfaces (GitHub, GitLab and Gitea) add more collaboration tools, such as:
NOTE! Issue trackers are commonly used to discuss specific (missing) features or bugs of code. There is a common implicit norm that issue trackers are places for technical-only discussions. This is a very limited understanding of what an issue could be. How can issue trackers be a place to discuss the implicancies of software? Who is part of these discussions, and (more importantly!) who is not?
An interesting example of an attempt to widen the use of issue trackers is the discussion thread that TiTiPi (The Institute for Technology in the Public Interest) opened in the git repository of the Electronic Health Certificates that would become part of the COVID QR code apps: https://github.com/ehn-dcc-development/hcert-spec/discussions/85. Where the first response was:
As this is not a technical issue with the specification, I will move this to the discussion forum.
Some web interfaces push specific collaboration tools, such as:
The wiki that we're using for the course runs on the same software as Wikipedia is running on, called MediaWiki. There are many more other types of wiki's, and each of them are slighly different in terms of interface and how the system works.
Wiki wiki is the first Hawai'ian term I learned on my first visit to the islands. The airport counter agent directed me to take the wiki wiki bus between terminals. I said what? He explained that wiki wiki meant quick. I was to find the quick bus. I did pick up a book about the language before my return home. I learned many things from this but wiki wiki is the word that sticks the most. https://web.archive.org/web/20080315215535/http://c2.com/doc/etymology.html
In 1995 Ward Cunningham described a wiki as "the simplest online database that could possibly work". The wiki was a way to share and collaborate on code and code-related ideas in a casual way. In fact, the wiki followed principles such as the collective code ownership, or code stewardship.
More design principles here: https://web.archive.org/web/20080329114249/http://c2.com/cgi/wiki?WikiDesignPrinciples
Video recording of Ward Cunningham talking about the wiki: https://en.wikipedia.org/wiki/File:Ward_Cunningham,_Inventor_of_the_Wiki.webm
Like Git, also wiki's are collaboration tools. They come with a range of features that shape collaborative work and introduces specific forms of sociality:
Like Git and MediaWiki, also Etherpad comes with different tools to shape collective work:
Etherpad is based on real-time conflict resolution, for which different algorithms have been used by the Etherpad project: Operational Transformation (OT) and Conflict-free replicated data types (CRDTs). These are used to follow the order of the changes that are being made, to make sure that Etherpad users are "on the same state".
Michael wrote about how Etherpad represents changes in the form of changesets, in an essay called Eventual Consistency : https://diversions.constantvzw.org/wiki/index.php?title=Eventual_Consistency (recommended reading if you're interested in collaboration systems or reading/writing machines!)
from IPython.display import IFrame IFrame("https://diversions.constantvzw.org/wiki/index.php?title=Eventual_Consistency", 1200, 600)
Collaboration is possible thanks to algorithms that resolve small conflicts about changes made by different people.
Person A can type:
Person B can edit is into:
Person C can make the word bold:
And in order to display these changes on everyone's screen and to stimulate collaboration, such changes are stored as (so called) "changesets".
There are 3 operators in this Changeset. There are 3 types of operators:
+. Operators describe different changes on the text beginning at the first Character of the Text.
=operator doesn't change the text, but it may change the attributes of the text (For example make it bold).
-operator removes text.
+Operator adds text with attributes.
This is a snippet from the essay, showing some examples of such changesets:
Changeset Interpretation -------------------- -------------------- Z:1>3*0+3$thi insert 3 characters: thi Z:4>2=3*0|1+2$s\n keep 3 chars, insert 1 line: s (newline) Z:6>2|1=5*0+2$is keep 1 line, insert 2 characters: is Z:8>1|1=5=2*0|1+1$\n keep 1 line, keep 2 characters, insert (newline) Z:9>2|2=8*0|1+2$a\n keep 2 lines, insert 1 line: a (newline) Z:b>2|3=a*0+2$te keep 3 lines, insert 2 characters: te Z:d>2|3=a=2*0+2$xt keep 3 lines, keep 2 characters, insert xt Z:f<1|3=a=2-1$ keep 3 lines, keep 2 characters, delete 1 character Z:e>1|3=a=2*0+1$s keep 3 lines, keep 2 characters, insert 1 character: s
Which brings all sorts of ways to collaborate and is now updated to make use of a new feature: real-time collaborative notebooks (!)
!!! NEEDS TESTING !!!
To use it, you need to be logged in to the soupboat with the same user.
We made a
shared user account that you can use for this.
Most of these tools also have an API (ta-ta-ta-tam!)
These API's make it possible to think of all sorts of other forms of collaboration, types of collective practice and software sociality. The allow for stretching existing tools and adding new features. The API's make the tools open ended for other types of usages.
Some examples of collaborative tools and collective practices made with these tools:
The Eventual Consistency essay by Michael introduces Epicpedia:
Inspired by the work of Berthold Brecht and the notion of Epic Theater, Epicpedia presents Wikipedia articles as screenplays, where each edit becomes an utterance performed by a cast of characters (both major and minor) that takes place over a span of time, typically many years. The work uses the API of wikipedia to retrieve for a given article the sequence of revisions, their corresponding user handles, the summary message (that allows editors to describe the nature of their edit), and the timestamp to then produce a differential reading.
And there are many more (to come)! :)