User:Riviera/Prototyping January 16 2024

On January 16th we spoke about three or four distinct, interrelated aspects of SI#23. Firstly, there was an overview of the prototyping sessions which we will have this trimester; what we will be doing week-to-week. Manetta and Joseph asked if there were any ‘prototyping needs’. People responded with various ideas and requests. Masters students are generously given free printing by Hogeschool Rotterdam. However, it is not possible to send print jobs to the School’s printers from a Linux machine. This incapacity could, following Janet Vertesi, be understood metaphorically as an infrastructural ‘seam’ (Vertesi 2014). To that extent, I stated that it would be good to look into stitching a solution together. Indeed, there are printers in the XPUB Studio but using these machines eats into the departmental budget. Joseph said this he would open a ticket articulating the lack of print capabilities on Linux machines. Personally, I would be interested to set up the computers in the Studio’s Internet Cafe Photograph of the Studio’s Internet Cafe such that they are able to print via the FollowMe system, where this is possible.

Webquilt demo

Secondly we discussed the webquilt which we are going to add to over the following ten weeks or so. Joseph explained that he produced the inner workings of the quilt using JavaScript, HTML and CSS. To add webpages to the quilt, as detailed in the git repository, it is necessary to add two lines of code to the head of each HTML page. There was a brief demonstration of how the quilt will work. There was also a short discussion about the history of webrings which are network structures adjacent to webquilts.

Adding a userpage to the webquilt

We were collectively tasked with adding individual user pages to the webquilt. These webpages are index.html pages which reside at /home/$USER/public_html on chopchop. Of course, it is not necessary for the webpages to be located on chopchop, the webpage could be hosted on a different server. I suggested earlier that only two lines of code are required to add a page to the quilt, although technically, a third line of code is necessary in another file: quilt.html.

quilt.html - the “database” file

The following code block illustrates the tree structure of SI23 Git Repository

https://git.xpub.nl/XPUB/SI23
├── README.md
└── web
    ├── index.html
    └── quilt
        ├── quilt.css
        ├── quilt.html
        └── quilt.js

quilt.html is accessible here. It illustrates the current status of the quilt; the pages which are adjacent to one another. It’s necessary to add an appropriate URL to the table on this webpage in order to be fully part of the webquilt. Openness emanates from the core of the technology underpinning the webquilt and this ethos informs our collective practice. So what, or who, determines which webpages are ultimately part of the quilt? We, the first year XPUB students, have accounts on the Gitea instance. Working with git in a collaborative mode is quite new to me. I have previously used the software to host a website, but was not worried about conflicts and branches as I was the only person actively pushing to that repository. In the case of SI23, there are many of us sending requests to the same place. This entails a set of social considerations. What are the implications of

Performing Git

Manetta stated that whilst taking part in algolit she encountered a video illustrating the workings of a ‘quick sort’ algorithm through the medium of an Hungarian folk dance. Inspired by this dance, Manetta guided us through a performative exercise in which we had to make pull and push requests to a git repository. Two actors were the git repository, the remaining actors were git users who were able to make push and pull requests to the git repository. I have chosen deliberately the term “user”. As Shusha Niederberger’s points out, ‘[d]espite their central position in data, users are considered only at the margins of the current critical discourses about the implications of data-driven environments’ (Niederberger 2023). Each git user was equipped with several, blank, paper cards approximately the size of an ISO/IEC 7810 ID-1 card. These were for writing git commit messages corresponding to individual changes made to “files”. These files were pieces of A4 paper with grid patterns printed on them. There were several aims to the game. The people playing the git repository had to keep track of the order in which the commits were received whilst responding to pull and push requests from the users. Users were able to write information in the files and commit their changes to the repository by sending push requests.

We engaged in two rounds with subtle changes to the rules in each round. The exercise presented an opportunity to think through software and imagine how software could be otherwise. During the exercise I had the chance to think like a git repository in the first round and like the user of a git repository in the second round. The movement from the former to the latter was interesting in itself. It was interesting to see how the git repositories implemented the logic of push and pull requests differently across the rounds.

Round One: Being a git repository with MariaX

In round one there were three files which the users were writing. These were called index.html, banana.jpeg and veryimportant.txt. I suggested to Maria that we keep track of the order in which we received the commits by adding timestamps to the commit messages. We did so, and when pull requests were made, one of us gave the cards we had available to the user making the pull request. With this system, the information about recent commits was always dispersed around the room. It was not possible to get a complete overview of all the commits. It was implicit that taking part in the performance effectively benefited from knowledge of how git works. However, it was simultaneously a learning opportunity and, as I mentioned earlier, the playful dimension encouraged imaginative thinking about how software such as git might function differently. Ultimately, the results spoke for themselves. There were some consistencies in the files, but there were also many discrepancies. Memorably, the question arose at to the issue of writing over one another. For example, during the exercise, one user drew a sheep in box 1,1 whilst another drew a cross in the same box. The effect of this was striking out the drawing of the sheep. Perhaps one reason for the differences between the files was partly attributable to the wide scope of possible drawings which could be placed in each box. These ranged from sheep to flowers, to crosses to block colours and there was some confusion amongst users about how to interpret the commit messages. However, I consider that much of the discrepancies were attributable to the way in which Maria and I served the git repository.

Round Two: Being the user of a git repository served by Senka and Victor

Senka and Victor handled pull and push requests in the second round. Simultaneously the rules were tightened up a bit such that only block colours could be placed in a given square on the file grid. Also, the users worked collectively on only one file.

Bibliography

Niederberger, Shusha. 2023. “CALLING THE USER: INTERPELLATION AND NARRATION OF USER SUBJECTIVITY IN MASTODON AND TRANS*FEMINIST SERVERS.” A Peer Reviewed Journal About 12 (1).

Vertesi, Janet. 2014. “Seamful Spaces: Heterogeneous Infrastructures in Interaction.” Science, Technology, & Human Values 39 (2). Sage Publications, Inc.: 264–284. https://www.jstor.org/stable/43671176.