No edit summary |
(copied over chapter notes from the pad) |
||
Line 1: | Line 1: | ||
==== | == '''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: <nowiki>https://time.cozy-cloud.net/</nowiki> | |||
=== Graceful ending === | |||
=== | === Side note: dealing with deprecated tools! === | ||
=== References === | |||
Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep | |||
<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