Chapter 3: Praxis Doubling: Difference between revisions

This page was last edited on 23 January 2025, at 18:34.
No edit summary
(copied over chapter notes from the pad)
Line 1: Line 1:
==== Artistic/Critical/Technical documentation/practice - praxis ====
== '''STRUCTURE:''' ==
Praxis doubling as a way reintegrate or reassemble labour, in response to practicing within more and more fractioned disciplines as a result of specialisation culture.


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


Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep
- highlighting syntactical/technical lingo,
 
       - eg using the star \* for transfeminist (reference the source)
 
       - explaining the use of technical metaphors
 
=== Positioning/argument: ===
- 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?
 
- 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 refelct on techincal docs
 
=== 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?
 
=== Reflection on technical choices: ===
- 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)
 
- 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
 
- 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: <nowiki>https://time.cozy-cloud.net/</nowiki>
 
=== Graceful ending ===


====== Questions about Docs: ======
=== Side note: dealing with deprecated tools! ===


* Installing Gitea on the other pi?
=== References ===
* Should we try to convert notes of setup of wiki4print into docs?


====== Resources for ref and inspo: ======


* <nowiki>https://infrastructures.us/</nowiki>
Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep
* <nowiki>https://sfpc.study/blog/solidarity-amidst-intifada</nowiki>
* The Undercommons, Moten and Harney. Logistics chapter.




<noinclude>
<noinclude>
[[Category:ServPub]]
[[index.php?title=Category:ServPub]]
</noinclude>
</noinclude>

Revision as of 18:34, 23 January 2025

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

Positioning/argument:

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

- 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 refelct on techincal docs

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?

Reflection on technical choices:

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

- 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

- 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


index.php?title=Category:ServPub