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. 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

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:

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?

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. 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

This might all be quite abstract. In the following section we'll look at some of the prototypes I have so far, to make it more tangible and point try to point out how they relate.

• 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

view gitpub prototypes

• printed versions of my personal reader (fork) and writing from the middle (copy) a repository writing exercise XPUB1
• included 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

users often indicate their real name in the commit message (which wouldnt be necessary bc there are user names but here ensures for others to know the person behind the made change) we can see that in etherpad too, but using author colors

Munkt: from youjung
Balint: Valentine added a new line

Script documentation

• 

  Gitpub v 0.1 (bash)

• 

  Gitpub v 0.2 (python)

• 

  Gitpub v 0.3 (python)

why

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

• (why gitpub and why make metadata visible)
• following points outline motivation for making gitpub and 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 example of collaborative version control software as publishing tool
• 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,
• yet 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) developing cultures
  • an industry that profits from maintaining compartmentalised, hidden labor and the divide between user and programmer (Hoff, 2020).

metadata as possible space for showing / navigating articulation work

• introduce 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
• jobs that involve much articulation work are nurses, secretaries, parents, air traffic controllers (Star, 1994)

• during writing exercises, became apparent a need for communication (additional text) alongside the shared process
• earlier I emphasized the 'actual work that people do when they write collaboratively'
• understand both as articulation work
• metadata as a space for articulation work or method to help navigate it?

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.

• 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 reserach

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.

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 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