User:Kim/Project Proposal (Gitpub): Difference between revisions

From XPUB & Lens-Based wiki
 
(29 intermediate revisions by the same user not shown)
Line 2: Line 2:
== What do you want to make? ==
== 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. This tool is not bound to any specific environment yet, but could have different interfaces such as a website or a terminal program. The information stored inside of every local .git folder builds basis of the tool. It allows to select and include different types of metadata, such as Commit Messages, Commit Authors, Timestamps or the amount of made changes. I would like to add options for styling the appearance of the publication through pre-made choices or custom CSS.
Gitpub is a tool to create a printed or web-based publication from a git repository including repository metadata.


The gitpub tool, which I aim to outline in the following paragraphs, poses the starting point, rather than the final outcome of this project. Possible divergencies include a deeper examination of collaborative writing softwares such as etherpad or wiki and the drafting of collaborative metadata writing scripts for them. Moving into a different direction, I would also be interested in using the multilayered text characteristics of version control software as a starting point for visual experimentations of reading and writing interfaces. Finally, a less computer, more personal, material focussed approach would introduce exercises in space, such as performing and writing text in different ways (together).
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.


<span id="how-do-you-plan-to-make-it"></span>
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.
== How do you plan to make it? ==
 
[[User:Kim/Prototyping 2nd year/GitPub| Prototype documentation]]<br>
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?
[[File:Gitpub.svg|thumb|documentation proof of concept (1)]]
 
[[File:Gitpub-2.svg|thumb|documentation local script (2)]]
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.


# At the moment (mon oct 27th) of updating this Project Proposal I have two script prototypes: a bash script that uses the gitlab api and has already been printed from and a python script, that makes use of the locally stored git metadata. Here are the further steps:
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.
# first up: prototyping workshop. in here I would like to test digital and or physical exercises that examine collaborative writing of, with and through metadata &gt; goal: share outcome in public moment (dec 5th)
# work on more specific features of gitpub and how to combine them &gt; goal: get to a running version of gitpub to use it for thesis writing  
# make the tool self contained, for example package it into a python program &gt; goal: share it with others
## design choices regarding the tools interface/options but also the publication outcome (how is meta information interacting with the main text?)
## peer distribution and testing rounds (individual or in the form of collective work sessions)
## documentation of the tool  
# divergency 1: examination of collaborative writing softwares
## explore collaboration and metadata mechanisms of etherpad and wiki
## write scripts such as gitpub for them
# divergency 2: visual experimentations of reading and writing interfaces through version control software
# divergency 3: personal exercises  
## research body, performative reading and writing exercises across different literary movements and groups
## test, test, test
## document


<span id="what-is-your-timetable"></span>
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.
== What is your timetable? ==


nov 5th: mock assessment (show process / discuss idea)
== How do you plan to make it? ==
[[User:Kim/Prototyping 2nd year/GitPub| Prototype documentation]]<br>
[[User:Kim/Prototyping 2nd year/Writing Scripts (Workshop)|collaborative writing exercises (workshop page)]]<br>
Printed prototypes:
<gallery>
Gitpub-v0.1-0.3.jpeg|printed prototypes v 0.1 & v 0.3
Prototypes-gitpub-v0.3-scans.jpg|scan v 0.3 personal reader
Gitpub-prototype-1.1.png|v 0.1 personal reader
</gallery>
Script documentation:
<gallery>
Gitpub.svg|Gitpub v 0.1 (bash)
Gitpub-2.svg|Gitpub v 0.2 (python)
Gitpubv03.svg|Gitpub v 0.3 (python)
</gallery>


nov 17th: prototyping workshop
current status:  


dec 5th: public moment tangible prototypes (documentation)
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.


dec 8th: assessment (formulate present state, way here, outlook)
further steps:


jan 30th: usable gitpub version with for thesis writing and producing
# prototyping workshop: develop and test collaborative writing exercises
# continue developing writing exercises and script prototypes in parallel
# combine different prototype features into one script
# test more collaborative writing exercises and first version of the tool: feed back into script writing
# make the tool self contained, for example package it into a python program
## 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
## 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
# tool peer distribution and testing rounds: feed back into script writing
# graduation show presentation
## performative (such as a reading)
## print outs (of versions, test runs, workshop results etc)
# documentation of the tool


<span id="why-do-you-want-to-make-it"></span>
<span id="what-is-your-timetable"></span>
== Why do you want to make it? ==


'''intro''' “tools as boundary objects that connect different communities of practice”<ref>Star, S.L. (1994). Misplaced Concretism and Concrete Situations: Feminism, Method, and Information Technology. In: Bowker, G. et al. (eds) Boundary objects and beyond: working with Leigh Star. Cambridge, Massachusetts: The MIT Press – encountered in Prototyping 2024/2025 intro</ref>
== What is your timetable? ==


'''writing and being written''' gitpub explores ''how we write and are written by software'' through the example of collaborative version control software as publishing tool. It emphasises the software as part of the writing.
{| class="wikitable"
|-
! 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
|}


'''extending existing software''' Gitpub builds upon git: a version control software, commonly interfaced with through platforms such as Github, Gitlab or Gittea, and on the local level with code editors or the terminal. Git is used to collaborate on code, track versions and progress of code and publish / document code. There are uses outside of this scope, such as the publishing and documenting of fonts or sharing of code unrelated resources.<ref>The Collective [https://www.byebyebinary.space/ Bye Bye Binary] uses GitLab for font developement and publishing https://gitlab.com/bye-bye-binary</ref><ref>“Always Already Programming” by Melanie Hoff, a text I often refer to, is published on GitHub https://gist.github.com/melaniehoff/95ca90df7ca47761dc3d3d58fead22d4</ref>


By deliberately extending and mis-using this existing piece of software I want to challenge its embeddedness into (white, male, optimisation driven) developing culture and an industry that profits from maintaining compartmentalised and 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”.<ref>I should cite this properly but for now, here is the secondary source: Franklin, U.M. and CBC Enterprises (1990). ''The Real World of Technology''. Montréal ; Toronto : CBC Enterprises. (Chapter 1)</ref> This notion links technology to culture, which we could define as “a set of socially accepted practices and values”. 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 cultural situatedness.
== 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.


Publishing a git repository with metadata in a printed form is an attempt to “connect different communities of practice”, to permeate the borders between otherwise diverged environments and examine the softwares cultural situatedness.
The above paradigm emphasises the software as part of the writing. In the following i will elaborate on the software as a part of community.


'''metadata''' Making 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, agential. social and political entity. This metadata is produced by means of version control, an integral part of the git software, that in practice is either neglected or exploited to reinforce hypercapitalist modes of production.
Gitpub is a tool in the sense of a “boundary object (Star, 1994) that connects different communities of practice (Star, 1994)” (pzwiki.wdka.nl, 2024).


'''visual''' Gitpub is not only about the script and technical aspects of metadata, which I have outlined above but also explores text (interfaces) and its boundaries on a visual level. I here want to question the authority of a (main) text by breaking away from its ordinary presentation, which makes its own rules seem invisible.<ref>and “Diagrammatic reasoning argues for graphic organization as a meaning producing system, one in which the organization of elements must be read in relation to each other.” footnote 9. both in Johanna Drucker, “Diagrammatic Writing”</ref>
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<ref>This 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).</ref>. 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).


'''note''' the above concerns the git software specifically but with adjustments could also be transferred to other tools such as mediawiki.
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.


<span id="who-can-help-you-and-how"></span>
== Who can help you and how? ==
== Who can help you and how? ==


I will seek technical support form the prototyping tutors (as of now Michael and Manetta). Other groups or individuals I would like to reach out for technical/ conceptual exchange could be the community around PrePostPrint and Constant. About Constant I know that they have been doing publications <ref>‘’Conversations’’ is a collection of dialogues between developers and designers involved in the wider ecosystem of Libre Graphics. https://conversations.tools/ The tools in use include etherpad, pandoc and bash and LATEX to transform into pdf. A graph mapping the tools also highlights git, but I am not sure about its actual role in the process. Concept, design and developement by Christoph Haag, Xavier Klein and Femke Snelting</ref><ref>‘’Aether 9’’ is another git related publication by constant and OSP that manetta pointed me to https://gitlab.constantvzw.org/osp/work.aether9/. There is not much documentation but I could find the publishers website https://greyscalepress.com/books/aether9/ and the collectives announcement https://web.archive.org/web/20130520210449/http://aether9.org/(archived). Working on this project were Gijs de Heij, Ludivine Loiseau and Pierre Marchand</ref> with git already and would be curious about their experience and workflows. I would also be curious to speak to members of OSP about ''visual culture'', a git based program which they build for their website and documentation.
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 <ref>’Conversations’’ is a collection of dialogues between developers and designers involved in the wider ecosystem of Libre Graphics. The tools in use include etherpad, pandoc and bash and LATEX to transform into pdf. A graph mapping the tools also highlights git, but I am not sure about its actual role in the process. Concept, design and development by Christoph Haag, Xavier Klein and Femke Snelting. [https://conversations.tools/ project website link]</ref><ref>‘’Aether 9’’ is another git related publication by constant and OSP that manetta pointed me to <nowiki>https://gitlab.constantvzw.org/osp/work.aether9/</nowiki>. There is not much documentation but I could find the publishers website <nowiki>https://greyscalepress.com/books/aether9/</nowiki> and the collectives announcement <nowiki>https://web.archive.org/web/20130520210449/http://aether9.org/(archived)</nowiki>. Working on this project were Gijs de Heij, Ludivine Loiseau and Pierre Marchand</ref> 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 [https://osp.kitchen/tools/visualculture/ visual culture], a git based program which the collective for their website and project documentation.  


<span id="relation-to-previous-practice"></span>
== Relation to previous practice ==
== Relation to previous practice ==
<gallery>
Tnb-web-interface.png|Tracing Networks Backwards (browser interface)
Layer-extension.png|layer (browser extension)
ToS-doc-2.JPG|Terms of Servers (terminal publication)
ToS-doc-4.jpg|Terms of Servers (printed output)
Si-27-print-publication.jpeg|Special Issue 27 (web to print publication)
</gallery>
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: [[User:Kim/Special Issue 1/Tracing Networks Backwards|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. [https://gitlab.com/km_kt/layer Layer] is a browser extension that surfaces different entities from a websites source code. Other previous projects of mine such as [https://words-on-margins.website/workshop/slides/index.html/ Writing on the margins of the web] (workshop) and [https://www.are.na/editorial/on-contamination 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.


Gitpub confuses centers of attention and makes its own making (processual, structural or meta information) part of its content. Herein gitpub poses a continuation to previous projects: ''Tracing Networks Backwards'' (browser game based on mediawiki) and ''Layer'' (browser extension) render information visible that is commonly hidden in graphical user interfaces. Both projects work through multiple levels of: showing hidden information, the way users interact with it and how it is merging with existing visual context. Other previous projects of mine such as [https://words-on-margins.website/workshop/slides/index.html/ Writing on the margins of the web] (workshop) and [https://www.are.na/editorial/on-contamination on contamination] (essay and performative reading) are more specifically concerned with the inner workings of a text through marginal and paratextual information and how they relate to, break with, penetrate the ‘main’ text.
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 [https://hub.xpub.nl/cerealbox/SI27/doc-website/pelican-site/output/ 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.


More recent experiments like ''Terms of servers'' (a terminal-first, then print publication) and the ''SI27 documentation'' (web to print using pelican and paged.js) sparked an interest in single source publishing workflows and the malleability of (markup) documents.
<span id="relation-to-a-larger-context"></span>


The above mentioned projects, and gitpub too, to some extend are all self referential. Through that, they address their own materiality, environment and concerns in ways that can be awkward, intimate and ambiguous.
== Relation to a larger context ==


In a wider context, I think of this as an attempt towards understanding processes and politics behind technologies in use and their embeddedness in social and cultural fields.
I understand Gitpub as situated in a lively ecology of experimental publishing tools, practices and concepts. There are for instance [https://osp.kitchen/ Open Source Publishing] and [https://prepostprint.org/ Pre Post Print] who practice graphic design and publishing with free software, rooted in collectivity and hacking based approaches. I here want name a few of the many existing publishing tools that, like gitpub, leverage free software. Octomode<ref>[https://cc.vvvvvvaria.org/wiki/Octomode Octomode] was developed by Mantetta Berends and Christina Cochior together with Varia.</ref> and Chattypub<ref>[https://www.hackersanddesigners.nl/chattypub.html Chattypub] was developed by Hackers and Designers</ref>, for example, are built for acts of low threshold collaborative publishing, while ikiwiki<ref>[https://ikiwiki.info/ ikiwiki] was developed by Joey Hess</ref> is more focused on converting wiki to html files using version control. Aesthetic programming<ref>here is a link to the [https://aesthetic-programming.net/ web version], and the [https://gitlab.com/aesthetic-programming/book git repository], developed by Open Source Publishing</ref> is a hybrid publication based on a git repository. Gitpub differs from the last two examples because it involves the version control metadata, not only within the writing process, but also as part of the outcome.


<span id="relation-to-a-larger-context"></span>
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 which he sees as central element to collaborative work. He criticises the stripping of context and variation as common engineering mistake (Murthaugh, 2019). Through this text I gained insights into the processes and boundaries of engineering human communication and collaboration in real time. Servanne Monjour and Nicolas Sauret, as part of the Aprübt publishing collective, propose gitterature as an alternative model for literature and editorial processes (Monjour and Sauret, 2021). While I share their understanding of the git writing environment as inherently processual, performative and conversational, my approach is to create a tool that is less platform based and meant to be reusable across multiple communities. Gitpub, as many of the above mentioned tools, is loosely connected to the UNIX design philosophy<ref>see also: [https://en.wikipedia.org/wiki/Unix_philosophy wikipedia], and discussed in context: [https://freeze.sh/_/2008/awkward/# Awkward Gestures] by Femke Snelting</ref> 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.
== Relation to a larger context ==


I understand Gitpub as situated in a lively ecology of experimental publishing tools, practices and concepts:  
== References ==
Boulding, K.E (1969). ''Technology and the changing social order''. in Popenoe, D. (ed) ''The Urban-Industrial Frontier''. New Brunswick, NJ: Rutgers University Press, pp. 126 – 140


=== practices: ===
Franklin, U.M. and CBC Enterprises (1990). ''The Real World of Technology''. Montréal ; Toronto : CBC Enterprises.


* Open source Publishing, especially their software [https://osp.kitchen/tools/visualculture/ visual culture], in use for their website and blog (?) displays commit messages on the website as documentation (which I think is super cool but sad if it means thats the only documentation that is written)
Hoff, M. (2020). Always Already Programming. ''Github Gist''. Available at: https://gist.github.com/melaniehoff/95ca90df7ca47761dc3d3d58fead22d4 [Accessed 13 Nov. 2025].
* Octomode (a tool made by manetta and christina with varia that uses etherpad as a basis for a print or web publication) and other adjacent etherpad-based tools
* Hackers and Designers with tools such as Chattypub
* publishing efforts by the INC (including “FROM PRINT TO EBOOKS A HYBRID PUBLISHING TOOLKIT FOR THE ARTS”, “.expub - Exploring Expanded Publishing”, “Screentime, Airtime, Facetime”)
* Pre post print


=== concepts: ===
Monjour, S. and Sauret, N. (2021). ''Pour une gittérature''. HAL (Le Centre pour la Communication Scientifique Directe), 2021, pp.237–252. doi:https://doi.org/10.48611/isbn.978-2-406-12363-7.p.0237.


* gitterature<ref>Servanne Monjour, Nicolas Sauret. Pour une gittérature. XXI/XX Reconnaissances littéraires, 2021, 2, pp. 237-252. 10.48611/isbn.978-2-406-12363-7.p.0237. hal-03962836 https://hal.parisnanterre.fr/hal-03962836/document</ref>
Murthaugh, M. (2019). Eventual Consistency. ''DiVersions''. Available at: https://diversions.constantvzw.org/wiki/index.php?title=Eventual_Consistency [Accessed 13 Nov. 2025].
* I feel there is a convergence with “Print is Flat, Code is deep”<ref>N. Katherine Hayles “Print is flat, code is deep – The Importance of Media-Specific Analysis”, Poetics Today (2004) 25 (1): 67–90. https://doi.org/10.1215/03335372-25-1-67</ref> but more in the sense of challenging Katherine Hayles argument than fully agreeing with her. After all does her thesis not reinforce a divide between digital and physical media, that today with notions of hybridity, post-print or experimental, is simply not there anymore?
* history of metadata
* database as symbolic form<ref>“Database as symbolic form” Lev Manovich (to be read fully)</ref>
* concept and uses of version control: specifically [https://aosabook.org/en/v2/git.html The Architecture of Open Source Applications (Volume 2) Git]  
* Eventual Consistency: michaels analysis of the history algorithms in collaborative text editing software against the backdrop of variation as central element to collaborative work and a common engineering mistake stripping of context
* UNIX design philosophy: emphasises small, specific tools, which are good at executing simple tasks with enough space left for users to build their own complex configurations. These small tools can work as modules since it is possible to connect them to each other often and in different ways.


<span id="references"></span>
pzwiki.wdka.nl. (2024). ''Prototyping 2024/2025 intro - XPUB &amp; Lens-Based wiki''. [online] Available at: https://pzwiki.wdka.nl/mediadesign/Prototyping_2024/2025_intro [Accessed 13 Nov. 2025].
== References ==


Star, S. L. (1994). ''Misplaced Concretism and Concrete Situations: Feminism, Method, and Information Technology''. In: Bowker, G. et al. (eds) Boundary objects and beyond: working with Leigh Star. Cambridge, Massachusetts: The MIT Press, pp. 143 – 170
<br><br>
<references />
<references />

Latest revision as of 10:52, 21 November 2025

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
collaborative writing exercises (workshop page)
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?

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 a part of community.

Gitpub is a tool in the sense of a “boundary object (Star, 1994) that connects different communities of practice (Star, 1994)” (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 situatedness[1]. 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 [2][3] 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 in collectivity and hacking based approaches. I here want name a few of the many existing publishing tools that, like gitpub, leverage free software. Octomode[4] and Chattypub[5], for example, are built for acts of low threshold collaborative publishing, while ikiwiki[6] is more focused on converting wiki to html files using version control. Aesthetic programming[7] is a hybrid publication based on a git repository. Gitpub differs from the last two examples because it involves the version control metadata, not only within the writing process, but also as part of 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 which he sees as central element to collaborative work. He criticises the stripping of context and variation as common engineering mistake (Murthaugh, 2019). Through this text I gained insights into the processes and boundaries of engineering human communication and collaboration in real time. Servanne Monjour and Nicolas Sauret, as part of the Aprübt publishing collective, propose gitterature as an alternative model for literature and editorial processes (Monjour and Sauret, 2021). While I share their understanding of the git writing environment as inherently processual, performative and conversational, my approach is to create a tool that is less platform based and meant to be reusable across multiple communities. Gitpub, as many of the above mentioned tools, is loosely connected to the UNIX design philosophy[8] 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.

References

Boulding, K.E (1969). Technology and the changing social order. in Popenoe, D. (ed) The Urban-Industrial Frontier. New Brunswick, NJ: Rutgers University Press, pp. 126 – 140

Franklin, U.M. and CBC Enterprises (1990). The Real World of Technology. Montréal ; Toronto : CBC Enterprises.

Hoff, M. (2020). Always Already Programming. Github Gist. Available at: https://gist.github.com/melaniehoff/95ca90df7ca47761dc3d3d58fead22d4 [Accessed 13 Nov. 2025].

Monjour, S. and Sauret, N. (2021). Pour une gittérature. HAL (Le Centre pour la Communication Scientifique Directe), 2021, pp.237–252. doi:https://doi.org/10.48611/isbn.978-2-406-12363-7.p.0237.

Murthaugh, M. (2019). Eventual Consistency. DiVersions. Available at: https://diversions.constantvzw.org/wiki/index.php?title=Eventual_Consistency [Accessed 13 Nov. 2025].

pzwiki.wdka.nl. (2024). Prototyping 2024/2025 intro - XPUB & Lens-Based wiki. [online] Available at: https://pzwiki.wdka.nl/mediadesign/Prototyping_2024/2025_intro [Accessed 13 Nov. 2025].

Star, S. L. (1994). Misplaced Concretism and Concrete Situations: Feminism, Method, and Information Technology. In: Bowker, G. et al. (eds) Boundary objects and beyond: working with Leigh Star. Cambridge, Massachusetts: The MIT Press, pp. 143 – 170

  1. ↑ This 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).
  2. ↑ ’Conversations’’ is a collection of dialogues between developers and designers involved in the wider ecosystem of Libre Graphics. The tools in use include etherpad, pandoc and bash and LATEX to transform into pdf. A graph mapping the tools also highlights git, but I am not sure about its actual role in the process. Concept, design and development by Christoph Haag, Xavier Klein and Femke Snelting. project website link
  3. ↑ ‘’Aether 9’’ is another git related publication by constant and OSP that manetta pointed me to https://gitlab.constantvzw.org/osp/work.aether9/. There is not much documentation but I could find the publishers website https://greyscalepress.com/books/aether9/ and the collectives announcement https://web.archive.org/web/20130520210449/http://aether9.org/(archived). Working on this project were Gijs de Heij, Ludivine Loiseau and Pierre Marchand
  4. ↑ Octomode was developed by Mantetta Berends and Christina Cochior together with Varia.
  5. ↑ Chattypub was developed by Hackers and Designers
  6. ↑ ikiwiki was developed by Joey Hess
  7. ↑ here is a link to the web version, and the git repository, developed by Open Source Publishing
  8. ↑ see also: wikipedia, and discussed in context: Awkward Gestures by Femke Snelting
Retrieved from "https://pzwiki.wdka.nl/mw-mediadesign/index.php?title=User:Kim/Project_Proposal_(Gitpub)&oldid=315998"