Chapter 3: Praxis Doubling

STRUCTURE:

Intro:

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

References

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