User:Kim/Assessment 2 (T4)

year 1

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?

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 for almost 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, making use of the malleability of markdown files

Technical: exercising python, bash scripting

terminal publication
printed output

links: project documentation, project process, directory on cerealbox

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: (after trying out multiple forms: wiki, websites, a mix of both or more local approaches like zotero) found an interest in about 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

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

project proposal

what

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 is 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) files that are contained inside a git repository. Yet this metadata is either neglected or exploited to reinforce hypercapitalist modes of production.

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

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.

gitpub is only one part of the project proposal:

while in the first part I am writing scripts (programming) its relevant to look at the (social, technological) scripts we follow when writing. here is why...

We use software such as git or etherpad to collaborate on a text. In the development of such software, acts of collaboration are anticipated and inscribed into these tools - think of version control, merging, branching or comments (see _metadata_). Those features influence how we use tools and thereby prescribe processes of writing together. In that a software becomes a model that tries to solve human communication and interaction through computer engineering.

tools are built for efficiency, writing a tool or script is a process of making things work. This leaves little to no space for the actual work that people do when they write collaboratively. The actual work that is messy, full of variation and discussion (see articulation work).

I would not like to separate above processes but ask how a script (which which forms the technical basis of the tool) and collaborative writing work (that we today look at through specific scores) can inform each other?

prototypes

why

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

(why gitpub and why make metadata visible) The following points outline my motivation for making gitpub and the possibilities I see in making metadata visible.

the software as part of the writing

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 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). 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 (what follows is a remark on the concept of 'naturalisation'). 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).

the writing exercises make apparent that there is a need for communication (additional text) alongside the shared process, which is where i see a connection to metadata.

metadata as possible space for showing / navigating articulation work

articulation work describes the work that enables work to happen - involving mostly communication and organization around work This type of work is done in real time, to manage unforeseen contingencies. Articulation work is often invisible or unrecognized. A few jobs that involve a lot of articulation work are nurses, secretaries, parents, air traffic controllers (Star, 1994).

Just now I mentioned the need for communication alongside a shared process, and earlier emphasized the 'actual work that people do when they write collaboratively'. And I think a big part of this is articulation work!

how

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

context

thesis

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.

project environment

Here is a non-exhaustive list of gitpubs larger context and its relation to it.

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. while also using git, Gitpub diﬀers 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.

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 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 which favours small, specific tools, that are built to perform simple tasks while leaving eno

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