_note: I'm using the words toolkit, handbook, map, collection of tools, practices or devices as interchangeable. Read it crossing your eyes, as a kind of not-fixed-superposition that will eventually stabilise during the research_
### What do you want to make?
### What do you want to make?
Focus on software documentation as an interface between code, users, developers, communities, and the world.
- A toolkit to explore _software documentation_ as publishing surface.
- An extensible set of tools and practices that focus on _software documentation_ as an interface between code, users, developers, communities, and the world.
- A handbook with a strong attention on the economy of different knowledges present in _software documentation_.
- A collection of small devices to assist and stimulate the documentation process, with prompts and gently reminders that _software documentation_ is a form of care, not just a source of profit.
- A series of writing prompts to experiment with software documentation as a generative device to keep thinking through code from different perspectives.
- A way to understand publishing as iterative process, as a format that grows and shrinks through versioning and embrances branching to adapt to specific environments.
Research how writing software documentation changes depending on the context and actors involved.
- A (loose, habitable, extensible) map to orientate around what does it mean to _make software_ besides just writing code.
Experiment with software documentation as a generative device to keep thinking through code from different perspectives.
- Something in between the refreshing shuffle of perspective in the Oblique Strategies, and the ability to infiltrate established practices like the Lottery of Babel.
- Something to be organized and shared as the Software Design Pattern, but to be discovered and performed as the Minecraft crafting system.
Explore software documentation as iterative process, as a format that grows and shrinks through versioning and embrances branching to adapt to specific environments.
Develop tools to facilitate rich software documentation. To assist and stimulate the writing process with prompts and gently reminders that software documentation is a form of care.
<!--- To question who gets to write it, who has to write it, who is left out.
- To use it as a writing machine, to build a world around software.
How this exchange of resources could make place for different voices. How writing _software documentation_ changes depending on the context and actors involved? -->
### How do you plan to make it?
### How do you plan to make it?
Define a domain of research. Where does software documentation begin and where does it end? What about tutorials, guidelines, and demos? How porous or tentacular is this surface? Set some references by looking back at the works made last year and read them through the axis of code and care.
_note: the plan is to use the different hackpacts and assignments as a way to bootstrap different directions for the research. Every hackpact is self contained and in effect is a different prototype, but it rarelly ends when a new one starts. Rather, with every new hackpact the old ones continue developing in the background with less intensity, but in concert, informing each other._
`[Hackpact 1 - Define a domain of research]`
Start writing documentation for selected prototypes from the many made last year: could this process create a new public, or transform their original ones?
Where does software documentation begin and where does it end? What about README files, tutorials, guidelines, comments in the source code, and demos? How porous or tentacular is this surface? Set some references by looking back at the works made last year and read them through the axis of code and care. Explore common templates of documentation and their habitability.
#### Work on several prototypes and their documentation
`[Hackpact 2 - Write documentation & focus on its contents and style]`
Write documentation for selected prototypes from the many made last year: could this process create a new public, or transform their original ones?
As initial case study focus on the Padliography, a tool developed within XPUB to keep track of the amount of scattered Etherpad documents used to take notes and work togheter. During last year it's been used only in the context of our class, but after some adjustments it's now flexible enough to be offered also to other constellations orbiting around the _XPUB & Lens-Based wiki_.
As initial case study focus on the Padliography, a tool developed within XPUB to keep track of the amount of scattered Etherpad documents used to take notes and work togheter. During last year it's been used only in the context of our class, but after some adjustments it's now flexible enough to be offered also to other constellations orbiting around the _XPUB & Lens-Based wiki_.
Open the writing process to include collaborative practices for the documentation of the Workbook. This is a joint project started with Supi to build an online-modular-workbook-cms to learn how analog synths work through interactive annotation.
What does it mean to offer it to someone else? How to talk the same language with different contexts? How to be clear without oversimplifying?
`[Hackpact 3 - Write documentation & focus on the process of writing]`
Write the documentation together. Could there be multiple voices or is necessary to keep a single point of view? Experiment with versioning. Try to have several instances of the same documentation.
Open the writing process and experiment collaborative practices for the documentation of the Workbook, a tool developed together with Supi to keep track and annotate configurations for different instruments and facilitate learning process.
Expand the research to tap into ongoing projects outside XPUB, such as freelance works and parallel research such as [OOC](../ooc-summer-session/).
Write the documentation together. Could there be multiple voices or is necessary to keep a single point of view? What does it mean to write with different intensities? Can we imagine ways to zoom in and out details level? How different knowledges can participate in this process?
<!-- ↓ actually this could be the main focus of the research ? -->
`[Hackpact 4 - Write documentation & focus on the surrounding context]`
Are there ways to make the documentation process more sustainable (socially, economically)? Are there strategies to overcome a low-resources environment? Search for escamotages to create space and energies to document. Work with collaborators, clients, and end-users to approach code from multiple point of view.
Expand the research to tap into ongoing projects outside XPUB, such as freelance work and parallel research such as [Object Oriented Choreography](../ooc-summer-session/), that is an ongoing project of mine related to networked technologies, VR and contemporary dance.
Are there ways to make the documentation process more sustainable (socially, economically)? Are there strategies to overcome low-resources environments? Search for escamotages to create space and energies to document. Use documentation to work with collaborators, clients, and end-users and approach code from multiple point of view.
Try to infiltrate the industry of software development through documentation. Attempt to expose their public to these questions in subtle ways. Offer entry points and escape routes from the automatic outcomes proposed by tech solutionism.
`[hackpact 5 - Write documentation & focus on who is writing it]`
What are the relations between documentation and the community around a software?
What are the relations between documentation and the community around a software?
<!-- TODO: inflate this ^ -->
- Experiment with versioning.
- Try to have several instances of the same documentation.
- Try to question who is writing and who is reading the documentation.
- Shift the moment in which the documentation happens.
- Where the documentation is hosted?
Question the nature of the documentation: what does it take for granted? For what kind of public it is produced, and what kind of public does it produce? How does it normalize the context around the software? What are its politics of access? How does it create entry points and how does it gatekeep?
Question the nature of the documentation: what does it take for granted? For what kind of public it is produced, and what kind of public does it produce? How does it normalize the context around the software? What are its politics of access? How does it create entry points and how does it gatekeep?
Try to infiltrate the industry of software development through documentation. Attempt to expose their public to these questions in subtle ways. Offer entry points and escape routes from the universal solution proposed by big corporates.
`[hackpact 6 7 8 - Towards final project]`
<!-- TODO: this more concrete approach here -->
- Collect and organize the outcomes from the different hackpacts.
- Trace trends and synthetize common and diverting aspects.
- Research on a surface that could host this different facets.
### What is your timetable?
Is it a deck of cards? A table tennis setup with different prompts printed on different balls? Is it a game? A manifesto? A CMS? A trekking route or a 400km pilgrimage?
**October**
How can it inhabit the places where documentation is hosted?
Define a domain of research. Do not decide on it's granularity.
### What is your timetable?
Define the premises where which to ground the project by revisiting first year projects.
**October**
Think about a glossary and possible formats to test some concept in a small scale, such as the first public moment at Leeszal or the freelance works.
- Define a domain of research.
- Understand where to ground the project by revisiting first year prototypes.
Experiment writing the documentation for the [Padliography](https://hub.xpub.nl/soupboat/padliography/) and the [Workbook](https://hub.xpub.nl/soupboat/workbook/).
- Think about a glossary and possible formats to test some concept in a small scale, such as the first public moment at Leeszal.
<!-- TODO: provide some context about padliography and workbook -->
- Experiment writing the documentation for the [Padliography](https://hub.xpub.nl/soupboat/padliography/) and the [Workbook](https://hub.xpub.nl/soupboat/workbook/).
**November**
**November**
Work on OOC for December performance at NaO Festival, Milan. What does it mean to document a bespoke tool developed just for this project? Experiment with the documentation for the interactive patch of OOC.
- Experiment writing documentation for project outside XPUB, both artistic and commercial ones.
- Explore the moments in which the documentation happens.
Get in touch with key figures to interview for research.
**December**
**December**
OOC performance in Milan.
- What does scientific literature have to say about software documentation?
Follow-up about the different documentation processes.
- Archeology of software documentation. From printed manuals to README files to CD/CI websites.
Gather material to have an historical overview of software documentation.
**January**
**January**
Gather material to have a critical overview around software documentation.
- Field research of the current trends in software documentation. Explore different contexts (solo, coop, corporate, floss, proprietary) and different coding languages.
Field research of the current state of software documentation. Explore different fields: big projects, small projects, corporate documentation and solo developers. Explore different languages and reflect on how they features are reflected in the documentation.
Experiment continuing writing the documentation for different prototypes. How does this process of writing documentation inform the process of writing the thesis?
- Follow up on the outcomes of the different hackpacts. Focus on
Experiment with the idea of versioning, branching, collaborative writing.
1. materiality of the documentation (style, contents, forms),
2. context around the documentation (actors, timeframe, hosting)
**February**
**February**
Read read read and write write write.
- Research and prototype possible formats for graduation project outcome. What surface could host this different factes together?
Interview and case studies from different communities?
- 15 min daily prototypes starting from the sentence `A _________ to explore software documentation as a __________`
Experiment with the idea of versioning, branching, collaborative writing.
**March**
**March**
Self-induce dreams about the final outcome with a follow-up on the thesis research.
- Follow up on February daily prototypes
Research and prototype possible formats for graduation project outcome.
