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 vast amount 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 through 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 modes 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. In doing so, can it reflect or expose its culture and dynamics of collaboration?

By examining how metadata and markup have shaped collaboration in the production of publications from manuscript culture until today, my thesis text poses an analytical backbone to the current project.

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. I plan multiple iterations of testing the writing exercises, mainly in the context of Prototyping Workshops with our class, but could also imagine to reach out to other contexts that I named in the section Who can hep you and how? 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 the script (which forms the technical basis of the tool) and exercises can inform each other.

Gitpub also explores the visual relation between text and context and tries to find ways of representing asynchronous writing processes in a static, printed publication.

How do you plan to make it?

Prototype documentation
Printed prototypes:

• 

  printed prototypes v 0.1 & v 0.3

• 

  scan v 0.3 personal reader

• 

  v 0.1 personal reader

Script documentation:

• 

  Gitpub v 0.1 (bash)

• 

  Gitpub v 0.2 (python)

• 

  Gitpub v 0.3 (python)

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
2. continue developing writing exercises and script prototypes in parallel
3. combine different prototype features into one script
4. test more collaborative writing exercises and first version of the tool: feed back into script writing
5. make the tool self contained, for example package it into a python program
   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
6. tool peer distribution and testing rounds: feed back into script writing
7. graduation show presentation
   1. performative (such as a reading)
   2. print outs (of versions, test runs, workshop results etc)
8. documentation of the tool

What is your timetable?

Date	Activity	Goal
nov 25	prototyping workshop: develop and test collaborative writing exercises	share outcome in the try out night on dec 1st
dec 25	in parallel, develop prototypes	test different features of the script and writing exercise formats
jan 26	combine more specific features of gitpub	a running version of the script to use it for my thesis writing
feb 26	test the tool collaboratively, continue testing collaborative writing exercises, with both: my class and peers indicated in who can help you and how section	feed back experiences of both into the tools script
mar 26	implement minimal viable features	minimal viable features and nice to haves are listed above, implementation depends on time available
apr 26	make the tool self contained	for (peer) distribution and further testing
may - jun 26	test the tool collaboratively (individual or in the form of collective work sessions) with both: my class and peers indicated in who can help you and how	feed back results of testing into the tools script
jul 26 (and after)	documentation (of the code and project artefacts) and presentation (e.g. in form of print material, performative reading)	for the 3rd Assessment and Graduate Show

Why do you want to make it?

94)” (pzwiki.wdka.nl, 2024).

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 situatednessThis goes along with Susan Leigh Star’s concept of naturalization: in which “de-situated” or “naturalized” objects become invisible to members of community of practice through omnipresence and use. A consequence of this process is a communities decreasing criticality towards the object (Star, 1994).. 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 (Hoff, 2020).

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

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 Open Source Publishing about visual culture, a git based program which the collective for their website and project documentation.

Relation to previous practice

• 

  Tracing Networks Backwards (browser interface)

• 

  layer (browser extension)

• 

  Terms of Servers (terminal publication)

• 

  Terms of Servers (printed output)

• 

  Special Issue 27 (web to print publication)

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 Special Issue 27 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.