- adjust second paragraph to better address audience
- rephrase quotes ?
- outline of chapters is:
- Lowering barriers to
- Welcoming diverse knowledges to
- Orientate software in the world
- how to quote propperly an introduction from a book series? (software studies)
- find where to put _code documentation_&_developers_ paragraphs
---
@ -27,33 +23,30 @@ The main focus of this research is to explore software documentation as surface
A way to situate programming in specific contexts.
Documentation brings an understanding on software by disclosing its magic. It reveals what can be done with it, and where are the limits. By lowering barriers and creating entry points, documentation broadens participation. It reaches not only beginners, but experienced programmers as well. It affects thinking about software continuously, and from different perspectives.
Documentation is a space that interfaces between the code, the user, the developer, and the world. A space where to welcome different voices: not just engineers, not just experts, not just dudes. A space to acknowledge the massive labor of care besides technicalities, often marginalized by coding culture.
The first chapter focuses on documentation as publishing surface. Who's reading, who is addressed, and what could be done differently.
A surface that could host principles in close contact with algorithms, letting them entangle and shape each other. A way to orientate our instruments towards "non-extractive relationships, but in the meantime, being accountable for the ones they are complicit with." (A Wishlist for Trans\*feminist Servers, 2022)
---
## Homework
Documentation brings an understanding on software by disclosing its magic. It reveals what can be done with it, and where are the limits. By lowering barriers and creating entry points, documentation broadens participation. It reaches not only beginners, but experienced programmers as well. It affects thinking about software continuously, and from different perspectives.
### Software documentation
The second part frames documentation as a crossroads, where different knowledges meet in the making of software.
The concepts of worlding, political aesthetic, and critical thinking can be applied to all sorts of technical manuals. The approaches and methods explored in this thesis although are mostly informed by practices related to code documentation. While reading, please bind the terms software, application, program, etc. to code. Software documentation? Code documentation.
Documentation is a space that interfaces between the code, the user, the developer, and the world. A space where to welcome different voices: not just engineers, not just experts, not just dudes. A space to acknowledge the massive labor of care besides technicalities, often marginalized by coding culture.
`not sure about next paragraph ? find accessible examples, at least a couple`
The third section is focused on worlding, and the relation between code, documentation practices and political aesthetic.
The perspective of this thesis is more aligned to the docs for [ImageMagick](https://imagemagick.org/index.php) than to the ones for [GIMP](https://www.gimp.org/).
Here documentation is seen as a surface that could host principles in close contact with algorithms, letting them entangle and shape each other. A way to orientate our instruments towards "non-extractive relationships, but in the meantime, being accountable for the ones they are complicit with." (A Wishlist for Trans\*feminist Servers, 2022)
### For developers
## Software documentation
Another term to dismantle here is _developer_. By stripping down every trace of professionalism and formal education, this text is meant for everyone that wants to tinker with code. No matter at which intensity, nor distance, nor experience. No matter if for work, if for fun, if for learning. No matter if actively involved in the development or maintainance or from the user perspective. Here the word _developer_ is used like a labcoat that one has to wears
The concepts of worlding, political aesthetic, and critical thinking can be applied to all sorts of technical manuals. However, the approaches and methods explored in this thesis are mostly informed by practices related to code documentation. While reading, please bind the terms software, application, program, etc. to code. Software documentation? Code documentation.
---
The perspective of this thesis is more aligned to the docs for [ImageMagick](https://imagemagick.org/script/command-line-processing.php), than to the ones for [GIMP](https://www.gimp.org/docs/).
I would like to blame the Capitalist Realism we are surviving in for this (probably not the case). For people to get identified with their profession. And the other way around: for activities being doomed by the aura of professionalism. Who is a developer? One who programs for a living or one who lives for programming? (based)
## For developers
Here a developer is someone tinkering with code. 1. one choose to participate 2. Expertise doesn't matter. Documentation is both a beginner and experienced user-friendly surface.
Another term to dismantle here is _developer_.
By stripping down every trace of professionalism and formal education, let's agree that a developer is someone who tinkers with code. No matter at which level, nor distance, nor experience. No matter if it is for work, for fun, for study. No matter if one is actively involved in the development of a tool, or comes from the user perspective. Ellen Ulman writes that programming is a disease, but the situation is even worse: code is contagious material, touch it once and you are a developer.
`potential caption for image`
_Who is a developer? One who programs for a living or one who lives for programming? (based)_
