You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
# Worlding and Software
|
|
|
|
|
|
|
|
How do you chose a particular programming language, a coding style, a development environment and ecosystem, an infrastructure where to run the code, and so on?
|
|
|
|
These are **not just technical choices**, but rather coding contingencies.
|
|
|
|
These contingencies are situated in precise economical, cultural, creative, political, and technical contexts. Programming then is not just sharing code, but sharing context. It's providing a perspective to look at the world before attempting to get some grip onto it with a script.
|
|
|
|
How to offer a point of view through the lens of software?
|
|
Who get to participate in this process of making meaning?
|
|
How to create a discourse for the code to inhabit?
|
|
How to stretch the affordances of code, besides, technicality, marketing, and advertisement?
|
|
|
|
## Enter documentation
|
|
|
|
Could software documentation:
|
|
|
|
1. be an ideal surface to build worlds?
|
|
2. be an interface between different knowledges?
|
|
3. be a device to trigger different kind of economy around situated software?
|
|
|
|
How can situated practices inform the process of documenting software?
|
|
And how can situated software inform the process of technical writing?
|
|
|
|
## Contents
|
|
|
|
The thesis is composed of different texts: some provide context and critical background to situate the research, while others consist in experiments of actual documentation written for software developed within our course.
|
|
|
|
Every piece of documentation will try to reflect on different angles.
|
|
|
|
|
|
|
|
More precisely these four aspects will be addressed:
|
|
|
|
- **Tone and style**
|
|
How to make a documentation more accessible? How to create multiple entry points in a complex topic? How to address different kind of users, and not just a generic one?
|
|
|
|
- **Participation**
|
|
Who gets to write, and who is forced to do it? How does development and technical writing interact? Is technical writing a subaltern position in the industry of software development?
|
|
|
|
- **Destination**
|
|
Who can read documentation? Who can access? Where is the documentation hosted? How does it relate with a bigger context, if any?
|
|
|
|
- **Susteinability**
|
|
How to face the lack of resources when approaching technical writing? Strategies to share workloads and collaboration. Strategies to take care of shared piece of software.
|
|
|
|
The critical and theoretical research will be weaved around the actual documentations, in order to create a discourse and annotate the development of this practice.
|
|
|
|
## Table of contents (draft)
|
|
|
|
0. **Coding Contingencies**
|
|
Situate software as cultural object and proposes documentation as a surface to explore it. Written as a simulation.
|