User:Kim/Project Proposal (Gitpub)

What do you want to make?

Gitpub is a tool to create a printed or web-based publication from a git repository including repository metadata.

Briefly diverging from the what question of this section, the following paragraphs contain a short introduction to git and metadata, to enable a shared understanding of both concepts.

Gitpub builds upon git: a software that helps you keep track of changes made in a file and lets you collaborate with others on the same files. The softwares means of collaboration and version control produce a lot of metadata to the code (or text) that is written inside a git directory. Yet this metadata is either neglected or exploited to reinforce hypercapitalist modes of production.

Historically metadata was used to index books in library catalogs. With increasing digitisation, these were turned into databases. Not only books contain metadata, but basically everything we want to index or process by a computer. Today metadata is deeply embedded in search-engine optimisation by expansion driven big tech companies that control digital platforms, data, and online markets. In that, digital cataloging metadata not only feeds into e-commerce but reinforces proprietary mode of knowledge production and circulation. Using gitpub to make metadata part of the publication is an act of decentering the main body of a text or work. Here the software in use becomes not just a means to an end of production but presents itself as material, social and political entity. Gitpub renders metadata, as information that is usually being processed by and for experts or machines, into text readable by anyone.

The gitpub tool, which I aim to outline throughout the following sections, poses the starting point, rather than the final outcome of this project.

Next to the technical aspect of writing scripts, I intend to make space for non computer (or software) centered interaction. For this I will draft a set of writing exercises that examine collaborative writing of, with and through metadata. The reality of collaborative writing is messy, full of variation and discussion. In contrast, developing a tool is a process of ‘making things work’, in which variation and ambiguity become a programming problem to solve. Making gitpub, I dont want to separate the above processes but aim to understand how can the script (which which forms the technical basis of the tool) and exercises can inform each other.

How do you plan to make it?

==add prototype images (and graphs?)== current status: Prototype gitpub v 0.3. is a python script. It uses metadata stored in local .git repository and transforms html and markdown files to a printable pdf. further steps: 1. prototyping workshop: develop and test collaborative writing exercises (1. round) > goal: share outcome in public moment on dec 5th. 2. work on more specific features of gitpub and how to combine them > goal: get to a running (pre) version of gitpub to use it for thesis writing 3. 2. round of collaborative writing exercises: test them with different groups and reflect outcomes back into the development of the script 4. make the tool self contained, for example package it into a python program > goal: share it with others 1. minimal viable product: terminal interface, File formats included in the publication: markdown + html, basic formatting of the printed publication and option for custom stylesheet, a script shared through gitlab and gossip 2. nice to haves: web interface, File formats included in the publication: code files (e.g. python, javascript), advanced formatting of the printed publication in the way main and meta text interact, downloadable as a python program 5. peer distribution and testing rounds (individual or in the form of collective work sessions) feed back into script writing 6. graduation show presentation 1. performative (such as a reading) 2. print outs (of versions, test runs, workshop results etc) 7. documentation of the tool

What is your timetable?

nov 25: articulating my ideas for thesis and project in words and prototypes (key dates: mock assessment 5th, prototyping workshop 17th, proposal and outline deadline 21st) dec 25: in parallel develop exercise and script prototypes into test versions (key dates: try out night 5th, assessment 8th) jan 26: develop gitpub script 1.0 for my own thesis writing and producing feb - march 26: implement (minimal viable) features into the tool apr - june 26: make the tool self contained and sharable, test tool collaboratively in different settings and with different prompts, implement adjustments july 26: documentation and presentation

Why do you want to make it?

gitpub explores how we write and are written by software through the example of collaborative version control software as publishing tool. When using software for text editing or collaboration (e.g. .git, etherpad, word, google docs, code editors) we assume to be in control of the text emerging in front of us. But additional to the text we consciously form, there is a lot more text produced, yet not directly by us. This additional text is often metadata, used to index and render machine readable what we typed. Text is therefore always created reciprocally, rather than one-way. With gitpub I want to expose how software writes us back, in other words, how the different modes and actors in the writing process influence each other.

The above paradigm emphasises the software as part of the writing. In the following i will elaborate on the software as part of a culture community.

Gitpub is a tool in the sense of a “boundary object(s) that connect different communities of practice”

The use of tools like git is highly cultural: different communities follow different protocols of use. Yet working with git in day to day operations, the familiarity of its gestures and rhythms conceals the softwares own ways of writing and its cultural situatedness. By deliberately extending and mis-using this existing piece of software I want to challenge its embeddedness into (white, male, optimisation driven) developing cultures and an industry that profits from maintaining compartmentalised, hidden labor and the divide between user and programmer.

Ursula Franklin introduced me to Kenneth Bouldings understanding of “technology as practice, as way of doing something”. This notion links the definition of technology to culture, which we could define as “a set of socially accepted practices and values”. Making a tool, while also building it upon existing software, I aim to gain an understanding of software (technology) through the culture (and communities) it is situated in.

this part is work in progress - connect communities of practice: - which communities (dev community, using their software, and experimental / artistic community, using their approach of critical, collaborative practice and material realm of low threshold print circulation) - why bring them in contact? (to understand that software is not just scripts, and text written in it not just bits, but culture, conventions of representation, abstraction and yet full of variation, ambiguity and discourse) - what is the role of metadata in this? can metadata reflect or expose culture, the dynamics of collaboration, of authorship? - gitpub is also visual exploration (aesthetic, interface)

Who can help you and how?

Next to the support I will seek from the prototyping tutors Michael and Manetta, I would like to reach out to the community around PrePostPrint and Constant for technical and conceptual exchange. About Constant I know that they have been doing publications with git already and would be curious about their experience and workflows. I would like to reach out to Pre Post print (and their extended arm in the Netherlands, including members of varia) to receive feedback on an early version of the gitpub tool. This could happen in a general meetup, a workshop format or personal exchange. I am also curious to speak to members of OSP about visual culture, a git based program which they build for their website and project documentation.

Relation to previous practice

==add images== In previous projects I have been interested in rendering information visible that remains hidden in common user interfaces. And think of ways how we interact with that information and how it relates to the content already there. Herein gitpub poses a continuation to previous projects: Tracing Networks Backwards is a browser game based on mediawiki. It allows the user to trace articles through wiki links and output the resulting path in a diagram. Layer is a browser extension that surfaces different entities from a websites source code. Other previous projects of mine such as Writing on the margins of the web (workshop) and on contamination (essay and performative reading) are more specifically concerned with the inner workings and hierarchies of a text, which I explore through marginal and paratextual information.

More recent experiments like Terms of servers (a publication that can be read on the command line and from there turned into a printed version) and the SI27 documentation (web to print publication using pelican and paged.js) sparked an interest in publishing workflows that are based on markup files and can be converted into multiple formats such as websites, pdf’s and ebooks.

Relation to a larger context

I understand Gitpub as situated in a lively ecology of experimental publishing tools, practices and concepts. There are for instance Open Source Publishing and Pre post print who practice graphic design and publishing with free software, rooted collectivity and hacking based approaches. I here want name a few of the many existing publishing tools that, like gitpub, leverage free software. Octomode and Chattypub, for example, are built for acts of low threshold collaborative publishing, while ikiwiki is more focused on converting wiki to html files using version control. Aesthetic programming is a hybrid publication based on a git repository. Gitpub differs from the last two mentioned examples in my approach of involving the version control, its metadata, the software in use, as of not only the process but the outcome. Lastly I want to mention a few theoretical approaches, that I relate gitpub to on a more conceptual basis. In Eventual Consistency Michael Murtaugh analyses the history of algorithms in collaborative text editing software against the backdrop of variation. He herein understands the latter as central element to collaborative work and criticises the stripping of context and variation as common engineering mistake. Servanne Monjour and Nicolas Sauret, as part of the Aprübt publishing collective, propose gitterature as an alternative model for literature and editorial processes. They understand the git writing environment as inherently processual, performative and conversational. Gitpub, as many of the above mentioned tools, is loosely connected to the UNIX design philosophy which favours small, specific tools, that are built to perform simple tasks while leaving enough space for users to build their own configurations or connect multiple tools to another.