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.
210 lines
7.9 KiB
Markdown
210 lines
7.9 KiB
Markdown
---
|
|
categories:
|
|
- GRS
|
|
- Writing
|
|
- Research
|
|
date: 03/11/2022
|
|
description: Outline for the thesis
|
|
slug: thesis-outline
|
|
title: Thesis Outline
|
|
---
|
|
|
|
<!-- ## Guidelines
|
|
|
|
```
|
|
What do you WANT to write?
|
|
What mode of address do you want to assume? How do you want your text to speak to the reader?
|
|
(this dictates the form: essayistic, academic, narrative, non-linier, script; diary; field report)
|
|
Be clear about HOW you want to tell your story.
|
|
Key issues you want to explore (what research questions do these lead to?)
|
|
|
|
Please think of only 3 key issues.
|
|
|
|
Once you identify these you can begin a chapter outline.
|
|
|
|
```
|
|
|
|
Discussion
|
|
|
|
```
|
|
Software documentation
|
|
Programming software
|
|
|
|
Struggling a lot finding a surface between people that develop software, use software, communities concerned find a place that speaks/connects those different worlds
|
|
|
|
User manual = documentation
|
|
|
|
Surface creates a world around it, creates barriers and possibilities
|
|
|
|
What is missing > world of documentation in software development, often just refers to technicalities, create a generous space to create community, different kind of policies/identities in software development
|
|
|
|
For project work on a kind of toolkit: a book of spells, recipes, set of tools and practice to think through software documentaiton
|
|
|
|
three main issues:
|
|
1. materiality of software documentation (surfaces used to read it make it)
|
|
2. the actors that participate in this idea of software documentation, roles in writing of software
|
|
3. idea of economy around software documentation, exchanges that happen, economy of knowledge (knowledge in developing of codes,...) exchanges of different kind of knowledges, a space to reclaim the importance of voices, value of different voices, beside the technical beside meritopractical approach
|
|
|
|
form:
|
|
not sure want to write more?
|
|
want to do the opposite of what is told
|
|
explore the idea of list as a writing surface
|
|
list are a big thing in programming as a structure, data structure, a lot of essays, articles that use code instead of writing (think these things are super-cringe) but would be interesting to abstract some things from code and use them as writing method
|
|
use these kind of technics as a writing method
|
|
template used in industry, offer different kind of approach about documentation and understand what do they say, what do they do
|
|
idea writing as code
|
|
|
|
example of that writing: ... replace words is writing
|
|
find a meaningful way, critical way to use the writing machines
|
|
|
|
>> do something that my mum could read
|
|
how to make sense of it also for others
|
|
|
|
last year started to work with idea of versioning, take already existing text and change some words to re-orient the context > text about graphic design as world buiidling, took the text and replaced some words and became software as world building
|
|
|
|
make outlines to start
|
|
start with the structure
|
|
content is about structure
|
|
|
|
project proposal more narrative/theoretical
|
|
thesis more practical
|
|
|
|
```
|
|
|
|
## about the form
|
|
|
|
- data structures (list, loop, conditional, tree) as writing machine
|
|
- automatic writing or developing tools to write
|
|
- haunted surfaces or how to re-enchant dry formats
|
|
|
|
## about the contents
|
|
|
|
ecology of software documentation
|
|
more zspecifically in the context of software programming
|
|
|
|
1. materiality
|
|
|
|
- what is written?
|
|
- making space for the code in the world and viceversa
|
|
- kind of language, intensity (level of details), accessibility
|
|
- how is it structured?
|
|
- surfaces
|
|
- reference
|
|
- manual
|
|
- forum
|
|
- tutorial
|
|
|
|
2. actors involved
|
|
|
|
- who has to write it?
|
|
- who gets to read it?
|
|
- who is excluded?
|
|
|
|
3. economy around it
|
|
|
|
- value of documentation
|
|
- documentation work is work
|
|
- economy of different knowledges
|
|
|
|
--- ok v2 ---
|
|
|
|
mode of address
|
|
|
|
- write with a mix of diverse registry, in order to have several layers of accessibility
|
|
|
|
- something that my parents, that are outside this bubble, could understand
|
|
|
|
- imagine the tone of a discussion around a technical manual: how can we make it more accessible? how can we make it more clear? some jokes not 100% related. technicalities. how could it work for someone with a different background?
|
|
|
|
- imagine a list, so in a way both ultra-linear and non-linear narration
|
|
|
|
- develop a writing machine for this. a specific way to write the thesis. that could be (ideas):
|
|
- tagging aesthetic:
|
|
- a lot of short pieces tagged with different categories
|
|
- that could be aggregated by topic, or chronologically or
|
|
-z
|
|
- sortable list
|
|
|
|
forms of the list
|
|
|
|
- a
|
|
- b
|
|
- c
|
|
- ... (can grow)
|
|
- e
|
|
- f
|
|
- g -->
|
|
|
|
<!-- What do you WANT to write?
|
|
What mode of address do you want to assume? How do you want your text to speak to the reader?
|
|
(this dictates the form: essayistic, academic, narrative, non-linier, script; diary; field report)
|
|
Be clear about HOW you want to tell your story.
|
|
Key issues you want to explore (what research questions do these lead to?)
|
|
|
|
Please think of only 3 key issues.
|
|
|
|
Once you identify these you can begin a chapter outline. -->
|
|
|
|
## Coding Contingencies.
|
|
|
|
I want to write about worlding around 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 contexts. Programming then is not just sharing code, but sharing context. It's providing a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script.
|
|
|
|
More specifically, I would like to focus on software documentation as a surface for world-building.
|
|
|
|
## Topological writing
|
|
|
|
> To make sense of multiplicity, we need to think and write in topological ways, discovering methods for laying out a space, for laying out spaces, and for defining paths to walk through these. _[John Law and Annemarie Mol, Complexities: Social Studies of Knowledge Practices]_
|
|
|
|
![semiotic triangle of graduation](address.jpg)
|
|
|
|
The topological way to think and write the thesis is to be found somewhere around:
|
|
|
|
- the list form used by LW in the Tractatus,
|
|
- the branching and merging pathways of version control systems, and
|
|
- the content aggregation approach of bookmarking tools such as are.na
|
|
|
|
At the moment I can see it as a feed with a tagging system. The plan is to gather contents and curate them in a non-linear fashion, so instead of following the index as a series of steps, imagine to read it as a coral-like creature, with materials forking and interfering with each other.
|
|
|
|
These contents will be a mix of diverse registry, from the essayistic to the technical to the anedoctic, in order to have several layers of accessibility. The consistency of the discourse will vary: some parts will be more narrative and some other more scattered.
|
|
|
|
![coral table of contents](toc.jpg)
|
|
|
|
1. **Coding Contingencies**
|
|
|
|
1. Context of software studies
|
|
2. Documentation as an interface between the code, the user, the developer, and the world.
|
|
|
|
2. **Documentation as worlding**
|
|
|
|
1. Excerpts from [API Worlding](../api-worldbuilding/), versioned essay from T. Dingsun.
|
|
|
|
2. When there is documentation
|
|
|
|
1. Language, modes of address.
|
|
2. Who writes? Who reads?
|
|
|
|
3. And when there is not
|
|
|
|
1. A space to reactivate/reclaim/reorientate code?
|
|
2. Ways of writing, economies of knowledges
|
|
3. Practice proposals
|
|
|
|
4. Worlding through documentations mixtape
|
|
|
|
1. Excerpts from documentations that world
|
|
2. Individuate approaches and angles
|
|
|
|
3. **Software as care**
|
|
|
|
1. Cases study articulated through the points emerged from 2.4.2
|
|
|
|
1. Soupboat
|
|
2. 100R
|
|
3. Permacomputing
|
|
|
|
2. A list of devices to articulate software documentation as a form of care (project overview)
|