User:Kim/Assessment 2 (T4)

you are looking at the backend of kims t4 assessment - find the webpage here

This is an attempt to use the git protocol as presentation protocol, thinking through the actions that the software prescribes. The presentation is structured by main tasks (commands) used when working with the software. for coherence, the order and hierarchy of commands is hereby slightly adjusted, commands might also be interpreted as words rather than code.

git init

somewhere on my computer I initialize a git repository. this poses the local context for my project: in it, i can find some relevant work from the past year.

Tracing Networks Backwards

Tracing Networks Backwards is a (browser) game based on mediawiki. Its interface displays all wiki page titles (circle) that link towards the currently open one (center). Playing the game, the user can recursively visit wiki pages and output their traced path into a graph.

Key: what happens when we render more / different information visible, than usually prescribed in user interfaces? how do we interact with it? what does recomposition of information imply for how we ... read, learn, move, understand relations

• 

  browser version

• 

  installation at ubik for SI25

• 

  graph printout after 4h of tracing networks backwards

links: browser version, project documentation, project process

Browser Extensions

Layer is a browser extension surfacing source code elements which by default are not part of a websites (or browsers) visible interface.
Annual rings is a browser extension which gets a websites age and grows a ring for each year the site is old.

Key: continuing with the question of making visible, but here leaving the 'original' interface as a starting point, deconstructing it is part of the users operation

• 

  annual rings browser extension

• 

  layer browser extension

• 

  layer browser extension

links: Layer (repository), annual rings (repository), project process

Terms of Servers

Terms of servers is a terminal based publication that runs on a temporary, communal server called Cerealbox. Working with the server over a year now evoked questions around its materiality and reliability. Together with Claudio, we discuss these questions among us, the users, but also direct them towards Cerealbox itself. Terms of servers' form is malleable, it can be read in a computer shell or as printed text.

Key: the collaborative writing process with Claudio on an etherpad that records the 'actual text' and conversation and feedback on the emerging text and navigating process at at the same time. This happened through

use of specific marks pointing out sections to revise (claudio, mostly for himself but also communicating to me the stage of the text to me)

?review

adding '+' when agreeing

(here I think it would be nice to insert the ping and uptime scripts you made as they indicate time) ++

excitement (conveyed by enthusiastic use of exclamation marks and other symbols)

this looks promising!!
!! claudio did you see: the exec.tpp example shows that you can actually run commands in the tpp and display their output !! (SO we could really run the scripts we had been prototyping)

all text remains on the pad (will not be deleted) to ensure ability to follow process and context for both collaborators

We do know that our server is a Raspberry Pi 4B, we covered its What? We also know its Where? ($ping is actually covering where bc it investigates the hub/ xvm connection...) which is at our school: WDKA, Rotterdam, how about its When?

clarification in dialogue

(the last two sentences I did not quite get) (yeah I put them here but I am not sure as well, will expand on this but maybe it is something not related)

posing questions, calls for reflection, to another in the process

lets discuss: what is it that we aim for with this investigation/ publication? what differentiates our writing from existing man/ documentation?

Technical: exercising python, bash scripting, working with markdown (single source publishing)

• 

  terminal publication

• 

  printed output

links: project documentation, project process, directory on cerealbox

Fediverse Instance

We (Kiara, Eleni, Claudio, and I) with support of Manetta, started installing a Mastodon Fork 'Glitch Sok' on Debby, an XPUB server, in order to create our own instance.

Key: it wasn't easy. we navigated the process in a group (which is usually done by an individual) involved different protocols, documentation, discussion (written and spoken), side research. frustration with existing documentation that assumes a lot of previous knowledge and installations

technical: debugging(?) dare to change code or settings you dont fully understand

links: Fediverse/Installation documentation

Personal Reader

In the first year of XPUB, every student is asked to start a personal reader. Mine is a git repository that has grown into a container for mapping reading progress, notes and outlines, planning reading and sorting read texts.

Key: not having used git much before, I found an interest in mis-/ reusing the metadata for a non-technical, non-optimization purposes but rather as textual layer

Technical: git

links: repository on gitlab, previous reader on wiki

git status

git status provides me with information about my current situation, use this as title for this project proposal section

project proposal page

git add

lets add some changes to the initialized repository. what do I propose?

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.

although we might all familiar with git I'll briefly contextualize it:

• git software: keep track of changes made in a file and collaborate with others on the same files
• softwares means of collaboration and version control produce vast amount of metadata to the code (or text) files contained in a git repository
• metadata either neglected or exploited, reinforce hypercapitalist modes of production

At this point i was asked to say a bit more about metadata:

• Historically metadata used to index books in library catalogs
• increasing digitisation turned into databases
• Not only books contain metadata, everything we want to index or process by a computer.

• Today metadata deeply embedded in search-engine optimisation through expansion driven big tech companies that control digital platforms, data, and online markets.
• metadata not only feeds into e-commerce but reinforces proprietary modes of knowledge production and circulation.

git checkout

gitpub is only one part of the project proposal: (on a new branch I'll briefly outline the second part)

writing script(s) - script(s) writing is a series of scores.

above I outlined the act of writing a script (programming gitpub) - scores look at the (social, technological) scripts we follow when writing.

• Collaborative production of text as crucial part of this project
• reality of collaborative writing is messy, full of variation and discussion
• contrast: developing a tool is a process of ‘making things work’ > variation and ambiguity become a programming problem to solve
• important for me to approach development of gitpub not from purely technical side
• (but with exercises that examine collaborative writing of, with and through metadata.)

How can a script (which which forms the technical basis of the tool) and collaborative writing work (examined in scores) inform each other?

git merge

This might all be quite abstract. In the following section we'll look at some of the prototypes I have so far, to merge the two mentioned approaches, make tangible and point out how they relate. (this is all work in progress, so mainly some first observations)

scores:

• writing exercises (scores) orient themselves along features of common collaborative writing software (score for merging, score for versioning, score for message) the workshop page can be found here User:Kim/Prototyping 2nd year/Writing Scripts (Workshop)

• in score for message participants added a character alternatingly
• not allowed to converse during the exercise
• What alternative methods for communication can you come up with to plan or navigate the writing process?

• 

  score for message

looking at their writing more closely, it becomes apparent that they use symbols (question mark, exclamation mark, X) and positioning of those to create rupture, indicate points of attention or mark the end of a line.

a method that, without planning, claudio and I used too, when writing together with on the etherpad for Terms of Servers

gitpub prototypes:

• comes in 3 versions in which I printed my personal reader (fork) (2x) and writing from the middle (copy) a repository writing exercise XPUB1
• the in the publication included repository metadata spans: commit messages (communication), diff / insertions / deletions (change scope), user name (authorship), date (temporality), branch (path / parallelity)

• 

  scan v 0.3 personal reader

• 

  scan v 0.3 writing from the middle (annotated)

• 

  printed prototypes v 0.1 & v 0.3

for the moment, lets focus on commit messages and inspect them more closely

• 'writing from the middle' commit messages are messy: indicate precise made changes, just 'commit message', jibberish like 'ooooooooo'
• are also conversational and expressive (use of emojis and punctuation marks)

Tommi: Container 08 ❤️
Inge van Velzen: oops... forgot html

Script documentation:

writing scripts is rather new to me, gain better understanding of what they do through non-code documentation

• 

  Gitpub v 0.1 (bash)

• 

  Gitpub v 0.2 (python)

• 

  Gitpub v 0.3 (python)

why

git commands dont leave much space for reasoning, suspend protocol for a moment to speak about why

following points outline motivation for making gitpub and possibilities I see in making metadata visible.

in gitpub, metadata is part of not only the process, a means to an end of production, but integral part of the text / publication.

the software as part of the writing

• using software for text editing or collaboration (e.g. .git, etherpad, word, google docs, code editors) we assume to be in control of text emerging before us
• But additional to text we consciously form, is a lot more text produced, not directly by us
• additional text is often metadata (to index and render machine readable what is typed)
• Text is always created reciprocally (rather than one-way)
• With gitpub exposing: how software writes us back, in other words, how the different modes and actors in the writing process influence each other.

the software as part of culture / 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)

• use of tools like git is highly cultural (different communities follow different protocols of use)
• 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.
• extending and mis-using existing piece of software I want to challenge its embeddedness into
  • (white, male, optimisation driven) development cultures
  • an industry that profits from maintaining compartmentalised, hidden labor and the divide between user and programmer (Hoff, 2020).

metadata in the context of articulation work

• articulation work describes the work that enables work to happen
• involving mostly communication and organization around work
• type of work is done in real time, managing unforeseen contingencies
• is often invisible or unrecognized

• during writing exercises, became apparent a need for communication (additional text) alongside / navigating the shared process
• understand this as articulation work
• metadata as a space for articulation work or method to help navigate it?

git commit -m "gitpub"

creates a snapshot of the staged changes - I am not going to repeat all of the above, commit also adds metadata to index it and render comprehensible across contexts (my metadata in the form of time (table) and next steps)

1. iterate on writing exercises in different contexts (possible further inquiries: look at distribution of roles, methods for personal reflection in the exercise process)
2. further prototypes of the gitpub script (use for thesis writing / making)
3. early gitpub testing with peers (xpub, varia) (february) to iterate on feedback
4. implement minimal viable features to the script in a back and forth with writing exercises
5. make gitpub self contained (e.g. python project)
6. presentation of tool and scores (graduate show) and documentation

read full: detailed steps, timetable

git push

pushing the made changes to a public / a remote repository, I am placing my changes in an outside context.

thesis

thesis outline

My thesis text poses a more analytical backbone to the current project. In there will look at how metadata and markup have shaped collaboration in the production of publications from manuscript culture until today. Making use of gitpub, the thesis will unfold across different bodies of text, which, commonly discarded as technical byproducts, here are made part of the argument itself. The text is divided in roughly 3 parts:

• historical examples examine text production and collaboration from individual (secular) transcription to methods like pecia system (predecessor of markup allow for distributed production, division of labor)
• metadata in the present observes shift from simple two dimensional transcription to distributed rendering (historically but also today when viewing browser markup rendering to server side, metadata based rendering)
• implications for collaborative work, drawing from project research

project environment

This is a non-exhaustive map of gitpubs larger context and situatedness in it.

I here want name a few of the many existing publishing tools that, like gitpub, leverage free software.

Chattypub and Octomode, 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. while also using git, 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.

gitterature (by Servanne Monjour and Nicolas Sauret, as part of the Aprübt publishing collective) as an alternative model for literature and editorial processes. 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 not platform based and meant to be shared across different communities.

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.

references

Hoff, M. (2020). Always Already Programming. Github Gist. Available at: https://gist.github.com/melaniehoff/95ca90df7ca47761dc3d3d58fead22d4 [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