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

- This chapter is built upon reflections upon writing the technical docs. In that sense its a recursive text, a companion for another text and is written in tandem with us rewriting the technical text <3

- highlighting syntactical/technical lingo,

       - eg using the star \* for transfeminist (reference the source)

       - explaining the use of technical metaphors

- What this chapter does:

   - re-figuring what docs do

   - sharking knowledge and making the technical knowledge accessible

   - do we want to talk about the interplay between techincal discourse and between sharing it in a pedagogical

- Explicitly referencing that our practice (in-grid) are doing many transdisciplinary things

- doubling praxis can first be introduced as the reality of more-than-double

- //Discourse of efficiency, depersonalised - docs being anonomous

- critiquing a "figure" and we can bring in Docs as a firuge

Context in servpub project:

- What do tech-docs do, What dont they do - poetic lists? - tell stories?

- How/why did we (in-grid specific) start making these docs?

• - learning through writing and sharing.

       - means for getting more in-grid members on board. The project itself was a response to Winnie Soons call for creating a trans\*feminist research project in London. (We don't yet know what makes this one so London: deliberatly working outside of institutions, skimming resources and distrubution skills) - should talk & ask Winnie about that/perspective

       - syster using it for other projects Les ask them about these strands!

- What emerged through that process, in terms of needs and processes?

- In depth explainaition of the technical practice (docs), and the social labour relations around it. highlighting where optimisation is prioritised and the industrial tools built around making that practice easy as possible

- learning / teaching? Self-teaching? how are the docs related to this?

* Star - infrastructuring - get reference from G

In-grid began to write docs as a practical necessity. We are a collective of individuals, who are subject to all the pressures which come to individuals, be they personal, physical, economic and circumstancial. We are majority fractional or precarious workers, and this means our numbers fluctate 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 a natural progression of our hoarder tendancies, and our instinct to record all of our thoughts, if chaotically, in case one of us might need them later.

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.

Positioning/argument (maybe better title like disobedient figuring):

- Contextualise within "standard" doc-writing norms. Engineering work-flows, reliance on docs to standardise practice and erase human nuance, etc. - do we also want to talk about disobedience here? - ref: Geohackers text

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.

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.

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.

- Importance of chainlinking a technical practice in one seemingly neutral spaces (docs) to other, more politically implicated contexts (work, efficiency, transparent methods, etc) - ref: Ahmed?

- Lucy Suchman, configuration paper

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

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

References

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