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?
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
- 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
- Docs become active (used, referenced, relevant) when we the need for building is shared, and others want to expand independant infras.
- "_we are reminded collectively that technical knowledge is not the only knowledge suitable for addressing the situations we find our-selves in_" and yet technical knowledge is what we are trying to spread with docs. (Suchman, Lucy, Human-Machine Reconfigurations: Plans and Situated Actions)
- Reference for G to add to plainish text
- while we still needed and wanted to keep our docs legible, what are the necessary deviations from the doc-making tradition that we need in order to address our readers, who, decidedly, were not other engineers. How do we write docs DIFFERENTLY but not necessarily more simply. We do not assume the ignorance or simple-mindedness of a non-technically educated (conditioned) readership. How do we write for solidarity?
- docs are for linear processes, breaking linearity was a major challeng you m
- Practicing protocols, workshoping the technical writing in none technical spaces, and using those protocols (refer to the handshake, client server discussions)
- docs assume that you start somewhere and end somewhere, but as we are writing this its evident that we started many times in different places, and ended in many more, and some have not even ended even though that part of the project is technically "done"
- also how we make docs accessible, adding intros that overview and question practices in a way all can engage.
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