Icon: ⟀⋒⌘
/\ means axis intersection through a place of interest.
STRUCTURE:
Intro:
Praxis doubling is itself a plural. The _ing on doubling is a process ongoing, a verb and an action that is taken in a number of different orientations. In this section we are looking at how In-grid has oriented its praxis in this coalition. Praxis itself being the combination of practice and theory, of code and conduct, and of docs and protocols. In this act of doubling praxis, we open up the ways of interpreting relations, and figuring their possibilities.
To feel this out these technical network relations together In-grid has built up a debugging method for technical docs. This entails making practice and their knowledges accessible, from these distributed knowledges form dialogues around how these technologies can be configured otherwise, and set intentions for other ways of practicing them. This methodology is meant to not only enable technical practice and it's knowledges to be in discourse with the imaginaries they are figured through, but to also orient these dialogues towards forming our own imaginaries and figures for them to be practiced through.
This work builds from Lucy Suchman's Configuration, where we aim to double the user/designer paradigm she critiques to form other ways of imagining and transforming our relationships to technologies.This doubling is also done through one of our key practices of moving from transparency to access, enabling our practices to be accessed and doubled into other forms and needs by others. We developed this approach informed by the concept of semi-plain language that Kelsie Acton notes in here chapter Plain Language for Disability Culture in Crip Authorship. Both in the language we try to use but also in the way we are trying to practice language and formats as plastic and maleable. In this thinking not only how we can make technical language accessible within the scope of plain language, but also what textures and curves can we leave on with the semi- that can enable change this discourse to figure out other infrastructures.
Context in Servpub project:
In-grid began to write docs as a practical necessity. We are majority fractional or precarious workers, and this means our numbers fluctuate in relation to availability fairly frequently. We are also varied in our areas of expertise, with all of us interested in some form of critical technical practice, but with personal priorities and concerns. We have therefore, since the beginning of our work together, written everything down in order to show our working to those who not there, or those who may not have the same technical understanding of a process. We have copious notes for every meeting we have held since we began working together. We also have notes from submeetings, workshops and conversations, screenshots of collaborative softwares and saved chat logs. These docs began as another extended note-taking exercise as part of this tendency to create excessive records in case one of us might need them later.
[Contrast this excessive note-taking with the selective clarification of technical docs. More info is not always better, the process of what info is the most helpful, while also avoiding the anxious need to document diaristtcally. Formal, commercial technical docs are often selective points of access to give the reader/user some information about the "product" ]
We became initially involved in this particular project through invitation from Winnie Soon, who explains this inciting incident in more detail in the chapter Platform Infrastruce (TBC). It came at a point where we as a collective were reasonably consistent, but yet to fully establish ourselves and our ways of organising. When we were invited to become involved in building the infrastructure for servpub, we were interested in supporting the development of a trans\*feminist collective community of practice within London, as much as we were from learning from others already working in these areas. It was at a stage in our careers, generally, where we were interested in learning more about the practical aspects of sysadministration and infrastructuring, but had little to no applied experience. This project therefore began as a teaching exercise, wherein more experienced practitioners from collectives Systerserver and Varia taught In-grid how we might build this platform, and walking us throught those processes using thier own documentation and experiences as guidance. Several members of In-grid were interested in attending these initial training moments, but because of other commitments weren't able to attend. Our notes at first, therefore, were a way of looping in those of us who were not able to be present.
These initial notes, and the exisiting documentation from others, and those provided by the makers of the softwares we used was initially enough, but over time it became apparent that there was too much assumed in the way we had written our notes, much of which was dispersed between several different authors, instructions without context which made it difficult to fix problems, or identify issues should they arrive.
* Star - infrastructuring - get reference from G
Positioning/argument (maybe better title like disobedient figuring):
Technical documentation are a technical form that is/was standardised within "traditional" computing context like computer engineering and before that from electrical and mechanical engineering. In those contexts, the purpose of throrough documentation was to provide a legible* means for understanding how something was built and from there be able to fix or build on top of it if needed. The professionalisation of this artifact however, also means that the docs become a compendium of standardised and streamled the process of building, which, more often than not does not always following a linear path. It also effectively erases the human presence from the work being done by prioritising efficiency and the institutional memory of the production company. Similarly, documentation for computational tools are built provide just enough information for a user** to be able to work with a product and fix it where needed without "costing" the production company in the form of time spent providing support. By design, docs do not usually reveal beyond a certain level of utility of a system. Open source platforms will make those part visible but not annottated or documented. That would usually remain inaccessible to anyone who doesn't already know how to navigate technical files.
Speaking of navigation, the servpub docs themselves exist in several forms, one on the Gitlab hosted by Systerserver, one on in-grid internal, shared Github and one on wiki4print under the :docs category section. From a practical perspective, this is a nebulous and difficult setup, making sure they are all up to date has been a challenge and indeed they are not all synced. There also exists separate docs for wiki4print (which are referenced from the wiki-to-print docs made by Varia (?) and hosted on their wikimedia page for the project.) which detail how to setup this platform where we co-authored and designed this book. This somewhat menacing setup is a reflection of how we attempted to respond to the form/conventions of technical docs. [expand on the progression of going from internal docs, to collectively hosted docs with Systerserver then to including them as a reference to this chapter].
Expand: Articulate our response to that. How can we offer a response, why? What is the percieved gap we are trying to fill with these proposed docs?
The documents created for Servpub began as a record of our process for the purpose of sharing knowledge and also inciting other member of the group to join the project.
But the process of creating something as seemingly neutral as techincal documentation, became more politically implicated as work, efficiency, transparent methods, etc became entangled in the choices we made.
Bring in disobedient technologies
* legibility can be contested when we talk about language written for and by a "specialist" group.
** this is a very non-human, commercialised role that is used to refer to an asbtract consumer of a tool as a product. It does not take into the account the reality, nuance, needs or real people with a desire or need to use / make-use-of-soemthing.
- Who can we reference as guides for this offering. Mentions of action research by other people
- ref. 'filing a bug report on bug reporting', writing technical docs that reflect on techincal docs
Directing attention to technical choices (do we even need this?):
- short overview and use this refernce the colophon!
- might have or refere to the diagrams of relations
- mention readical referencing and point to colophon
- should mention the technical choices of the docs (not hardware) as that wont be in the colophon
ref:
- "Software does not come withour its world" - Maria Bellacasa quoted in geohackers text
Activating the docs
Throughout this practice of technical docs we have been questioning how we can enable them to not only work across abilities and knowledges but also open up the technical practices they document to be interpretable and localised. In this section, In-grid reflects deeper on how we have inquired into this later step, enabling the docs and the practices they describe to be re-interpretable and re(con)figure-able by non-experts. To do this, we formed a set of workshops from these docs that brought people together to do some basic sysadmin together, but along the way make space to highlight and take time to question the normalised and pedimented figures and relations of these infrastructures. We developed this workshop method as a way to not only make accessible the often obfuscated and encrypted practices of digital infrastructure, but to also bring them into dialogue with the operational concepts and metaphors they operate through. In doing this, we aimed to make a space where people can bring their embodied knowledges people have gained from doing these things, with the situated knowledges they brought with them. For us this was a space for us to think how we can bring in the methods of Amoore's (ref) cloud ethics as well as TITiPI's disobedient action research to open up and collectively dispute what these systems are, how they feel, and what we would want to imagine and metaphor them as.
We ran these workshops in two sessions, one at a combined panel at 4S/EASST in Amsterdamn, and the other internally starting to set up In-grid's own digital infrastructures. The workshop at 4S/Easst was run alongside a panel we ran exploring collective infrastructures, where we presented alongside TITiPI, NEoN digital, Júlia Nueno, as well as members of SHAPE on this project. The panel presented a spectrum of community organised infrastructure, and this workshop alongside meant to make accessible to the public In-grid's practices of collective re(con)figuring. The second workshop was run internally for In-grid members who were not specifically involved within Servpub and may have missed out on learning these skills or understanding these practices and their knowledges. This second workshop within In-grid also importantly moved from being an accessible representational process like we did at 4S/EASST to instead set up a VPS and foundational digital infrastructure for In-grid. In setting up this foundational infrastructure through this re(con)figuring practice, we aimed to have set it up with our own collective intentions.
Annotating the Chapter with snippets from the docs
ref: https://time.cozy-cloud.net/
Graceful ending
Side note: dealing with deprecated tools!
References
Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep