Chapter 3: Praxis Doubling

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 surface the ways In-grid has been In-countering these promised relations in practice, and in doing so figuring out their promise to us.

To feel out these technical network relations together In-grid has built up a debugging practice of technical docs. This research oriented making technical docs more critically accessible and flexible (Hamraie, 2017) to being situated through local knowledges and collective intentions. This methodology is meant to not only form wiggle room around technical practice and it's knowledges so that the can be in discourse with their pre-figure imaginaires imaginaries , but so that they can also orient these dialogues towards forming our own imaginaries and figures around them and to be practiced with. 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 (2023). 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 critical inquiring not only asking how we can make technical language more accessible within the scope of plain-ish language, but also what impressinons we can make with the semi- that changes this discourse to figure out other localised disputable social relations of infrastructuring.

Background to the Docs

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 each with our own personal priorities and concerns. We have therefore, since the beginning of our work together, written everything down in order to share our working with those who not there, and in a way where those who may not have the same technical understanding of a process can still input. 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 emerged from this pile of notes as an extended note-structuring exercise as part of this tendency to create excessive records of our collective figurings out of procces.

We took on this particular project through invitation from Winnie Soon, who explains this inciting incident in more detail in the chapter Platform Infrastructure (TBC). [no need: 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 other communities already working in these areas. It was at a stage in our collective where we were interested in learning more about the practical aspects of sysadministration and infrastructuring as we wanted to start to In-frastructure In-grid, but had scattered technical knowledges and little to no applied experience. This project then started through lots of knowledge exchange, wherein more experienced practitioners from collectives such as Systerserver, Varia, and CC shared with In-grid how to make these types of infrastructure as we made it. Several members of In-grid were interested in attending these initial training moments, but because of other commitments many In-grid members weren't able to attend. Our notes at first were a way of looping in and making accessible the knowledges and practices to those of us who did not have the capacity to be present.

These initial notes included references to documentation from other collaborating groups, and to "official" documentation provided by the makers of the softwares we used. Over time it became apparent that this particular local setup, of In-grid In-ServPub, needed it's own technical docs to figure out and make knowable our stories, relations and practices around this infrastructure. This also gave us room to address some of our own desires and intentions for critically accesible technical docs. To address assumptions about technical platforms, access, prior knowledge, and the often presumed ability of the reader/user to identify when and how to "troubleshoot" a problem.

[ \/ Contrast this excessive note-taking with the selective clarification of technical docs. \/ ]

{I also like below but maybe add to tech doc critique below}

More information is not always better, the process of what info is the most helpful, while also avoiding the anxious need to document diaristtcally. Standardized commercial technical docs on the other hand are often selective points of access to give the reader/user some basic information that enables them to use the product/tool, just enough information to make a tool usable in the way it was intended to be and by the people they intend to use them. Then there is the instructive text of DIY documents, which can be considered a form of documentation in their own right.

* Star - infrastructuring - get reference from G

Sedimented Norms Positioning/argument (or disobedient figuring):

Technical documentation are a technical form that has been standardised and sedimented within "traditional" computing context like computer engineering and before that from electrical and mechanical engineering [Can we get a ref]. In these contexts, the promise of technial documentation is to provide a legible understanding of how something was built and from there be able to maintain it within specific regimes and to develop it further within specific imaginaries of the system it is embeded within. The professionalisation of this artifact however, also means that the docs become a compendium of standardised and streamlined process of building, which, more often than not does not always follow a linear path. These docs through their efficient use give selective points of access to knowledge and practices that give the reader/user information that enables them to use the product/tool. The slection here orients them to give just enough information to make the tool usable in the way it was intended to be, but also encoded so that only the specific people can access them. With Aimi Hamraie's tracing of the figure of the Flexible User (2017) it can be understdood as a shaping of users and experts through flexings of bodies towards determinate machines and systems.

Through this encoding, encrypting and isolation of specific practices and their knowledges is also the erasure of the affective and human presence from the work. By prioritising efficiency systems and the sedimented institutional norms, these docs do not document the ways they demand bodies, communities, their infrastructures, and their knowledges to bend to their sedimented axis of politics in practice.

With Miriyam Aouragh and Paula Chakravartty's Infrastructures of empire (2016), we can unerstood how these promises of technological freedoms through specific determinate infrastructures, can bring with them their background and often the dominant militiaristic protocols and politics they are produced through.

Similarly, documentation for computational tools are built to 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 customer support. By design, docs do not usually reveal beyond a certain level of utility of a system. Open source platforms will make more parts visible but not annotated or documented. That would usually remain inaccessible to anyone who doesn't already know how to navigate technical files or code.

Srevpub Docs In-Praxis

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?

[Maybe the "Context of ServPub" can go here?]

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. The docs that we eventually arrived at are somewhere between internal notes, technical docs and DIY instructions; a simply-written, narrative-moderate, set of instructions on building a self-hosted server with a VPN, set up for collective management/sysadministration.

Bring in disobedient technologies

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. [Needs clarification: 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

This should probably happen through out?

ref: https://time.cozy-cloud.net/

Side note: dealing with deprecated tools!

This can be moved from side note to being a sub title

Shortly after completing the project, we found out that the VPN software we used, Tinc, is getting deprecated. This means.....

We decided not to "update" ServPub, or rather, we decided to keep the work and the documentation about it in the state it was left when we could no longer afford more time or resources to keep working on it. [needs expansion]

References

Acton, Kelsie. 2023. ‘Plain Language for Disability Culture’. In Crip Authorship, edited by Mara Mills and Rebecca Sanchez. New York University Press. https://doi.org/10.18574/nyu/9781479819386.003.0008.

Aouragh, Miriyam, and Paula Chakravartty. 2016. ‘Infrastructures of Empire: Towards a Critical Geopolitics of Media and Information Studies’. Media, Culture & Society 38 (4): 4. https://doi.org/10.1177/0163443716643007.

Hamraie, Aimi. 2017. ‘Flexible Users: From the Average Body to a Range of Users’. In Building Access. Universal Design and the Politics of Disability. University of Minnesota Press. https://doi.org/10.5749/j.ctt1pwt79d.6.

Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep