Research on software documentation as an interface between code, users, developers, communities, and the world.
### What do you want to make?
Explore documentation from the perspective of software as a form of care.
Documenting software it's a difficult and delicate practice.
Focus on software documentation as an interface between code, users, developers, communities, and the world.
Writing documentation it's more difficult than writing software itself.
It requires a lot of time and energy, and it involves many different skills: writing, coding, knowing how to share and at which intensity.
As some piece of code would write: I am documented, therefore I am.
Research how writing software documentation changes depending on the context and actors involved.
Undocumented software is invisible, but for the eyes of their own developers. And eventually, it begins to fade as soon as the developer looks away.
Experiment with software documentation as a generative device to keep thinking through code from multiple and different perspectives.
### What do you want to make?
Explore software documentation as iterative process, that grows and shrinks through versioning, and embrances branching to adapt to other environments.
Writing software as a form of care.
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.
What kind of resources, experiences and approaches constitute this practice?
<!--What kind of resources, experiences and approaches constitute this practice?-->
Research how writing software changes depending on the context and actors involved. Bring the specificities of different case studies: coding for oneself, coding for others, coding together with others. How can different nuances of these three settings inform and resonate one with the others?
<!--Research how writing software changes depending on the context and actors involved. Bring the specificities of different case studies: coding for oneself, coding for others, coding together with others. How can different nuances of these three settings inform and resonate one with the others?-->
Elaborate on the idea of care. Care for who and in which way? Care for what and from which perspective? Lay out these different subjects and annotate the ways they interact, reinforce, or dampen each other. Where and how to orientate software development in this chart?
<!--Elaborate on the idea of care. Care for who and in which way? Care for what and from which perspective? Lay out these different subjects and annotate the ways they interact, reinforce, or dampen each other. Where and how to orientate software development in this chart?-->
Try to make a public for this practice in subtle ways: how to offer entry points for (or escape routes from) the stereotypical western white male macho programmer? Is it possible to infiltrate the ultra efficient and violent industry of software development, seasoning its own tools? How to intercept some established practices and branch from them? How to publish outside our safe XPUB bubble?
<!--Try to make a public for this practice in subtle ways: how to offer entry points for (or escape routes from) the stereotypical western white male macho programmer? Is it possible to infiltrate the ultra efficient and violent industry of software development, seasoning its own tools? How to intercept some established practices and branch from them? How to publish outside our safe XPUB bubble?-->
### How do you plan to make it?
### How do you plan to make it?
There are three main nodes in the graph of this project. Writing software, taking care, and staying low.
Define a domain of research. Where does software documentation begin and where does it end? What about tutorial, guideline, and demo? How porous is this surface?
Start to set some coordinates by looking back at the works made last year and read them through the axis of code and care. Or some other system of coordinates that suits better.
Expand the research to tap into projects outside XPUB, such as freelance works and [artistic research](../ooc-summer-session/). Are there ways to make the documentation process more sustainable? Which strategies to overcome a low resources environment?
Writing software and taking care are meant to be moments of research and curation of contents in the form of resources, experiences and approaches. Starting from the assumption that there is no universal solution for writing software, and that coding is always site specific, this research could set some coordinates by looking back at the works made last year and analyze them through the lenses of code and care.
Question the nature of the documentation: what does it take for granted? For what kind of public is it 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?
Along with this initial reflection on the first year, the plan is to focus on three case-studies of different nature. One in which I develop for myself, one in which I develop for someone else, and one in which I develop together with some others. These projects will not start from scratch, I
Try to infiltrate the industry of software development through their documentation. Attempt to expose their typical public to these questions in subtle ways. Offer entry points and escape routes from the universal solution proposed by big corporates.
Developing for myself could happen in the context of [Object Oriented Choreography](../ooc-summer-session/), a long-term contemporary dance research with VR and networked media. The team I'm working with for this project is small, and I'm the one in charge of the art direction and interaction design.
<!-- There are three main nodes in the graph of this project. Writing software, taking care, and staying low. -->
Developing for someone else refers to commisioned and freelance work. It could be a way to bring not only the advantages, but also the perspective and cultural dynamics of F/LOSS into commercial practices. My freelance work usually consists in developing websites or interactive application to be used in performative context. It could be a way to orientate specific commision to the development of tools of general use.
<!-- Writing software and taking care are meant to be moments of research and curation of contents in the form of resources, experiences and approaches. Starting from the assumption that there is no universal solution for writing software, and that coding is always site specific, this research could set some coordinates by looking back at the works made last year and analyze them through the lenses of code and care. -->
Developing togheter with others it's a way to renegotiate priorities when developing software. How do we value and balance between accessibility, flexibility and sustenaibility? This could happen either collaborating with someone from XPUB (think for example to the [workbook](../workbook/) with supi, the ilizarov projects with gr, etc ) or intercepting some external realities' need to craft together some piece of site-specific software.
<!-- Along with this initial reflection on the first year, the plan is to focus on three case-studies of different nature. One in which I develop for myself, one in which I develop for someone else, and one in which I develop together with some others. These projects will not start from scratch, I -->
[... staying low]
<!-- Developing for myself could happen in the context of [Object Oriented Choreography](../ooc-summer-session/), a long-term contemporary dance research with VR and networked media. The team I'm working with for this project is small, and I'm the one in charge of the art direction and interaction design. -->
<!-- Developing for someone else refers to commisioned and freelance work. It could be a way to bring not only the advantages, but also the perspective and cultural dynamics of F/LOSS into commercial practices. My freelance work usually consists in developing websites or interactive application to be used in performative context. It could be a way to orientate specific commision to the development of tools of general use. -->
<!-- Developing togheter with others it's a way to renegotiate priorities when developing software. How do we value and balance between accessibility, flexibility and sustenaibility? This could happen either collaborating with someone from XPUB (think for example to the [workbook](../workbook/) with supi, the ilizarov projects with gr, etc ) or intercepting some external realities' need to craft together some piece of site-specific software. -->
<!-- [... staying low] -->
### What is your timetable?
### What is your timetable?
**October**
**October**
Define practically a method for the methodology: think about protocols and possible formats for graduation project outcome.
Define the premises in which to ground the three projects by revisiting first year projects. Draw a political compass of software as care.
<!-- Define practically a method for the methodology: think about protocols and possible formats for graduation project outcome.
Get in touch with different communities for case study 2 and 3.
Get in touch with different communities for case study 2 and 3. -->
Define a domain of research. Do not decide on it's granularity.
Define the premises where which to ground the project by revisiting first year projects. Draw a political compass of software as care.
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 for Non-Linear and CLI.
**November**
**November**
Work on OOC, preparing for December performance at NaO Festival, Milan.
Develop context and prep-works for case study 2 and 3: plan timetable.
<!-- Work on OOC, preparing for December performance at NaO Festival, Milan. -->
<!-- Develop context and prep-works for case study 2 and 3: plan timetable. -->
Get in touch with key figures to interview for research.
Get in touch with key figures to interview for research.
**December**
**December**
@ -103,7 +118,7 @@ control, frame the world in a form that you can control and act on from a really
i would like to research on the question: can we do it in another way? giving back something and not only take
i would like to research on the question: can we do it in another way? giving back something and not only take
when you're using a tool you can learn the world throught the use of it, the difference is: can i use the scissors to cut a piece of paper and make a notebook or kill someone? -->
when you're using a tool you can learn the world throught the use of it, the difference is: can i use the scissors to cut a piece of paper and make a notebook or kill someone? -->
This is a list of current trends that the software industry enforces and naturalize.
<!--This is a list of current trends that the software industry enforces and naturalize.
Software comes from a really specific occidental cultural tradition.
Software comes from a really specific occidental cultural tradition.
Software tends to priviledge masculine, binary, exploitative and extractive practices.
Software tends to priviledge masculine, binary, exploitative and extractive practices.
@ -112,7 +127,13 @@ Software comes invisible, transparent, neutral.
Software models the world in order to control it.
Software models the world in order to control it.
To make software means not only to write code, but also to take a stance regarding this trends.
To make software means not only to write code, but also to take a stance regarding this trends.
With this project the intention is to situate my practice within ethical yet sustainable boundaries.
With this project the intention is to situate my practice within ethical yet sustainable boundaries. -->
Documenting software it's a complex practice. Documenting software is a process of translation. Writing documentation it's more difficult than writing software itself. It requires a lot of time and energy, and it involves many different skills: writing, coding, knowing how to share and at which intensity.
As a piece of code would write: I am documented, therefore I am. And viceversa.
Undocumented software is invisible, but for the eyes of their own developers. And eventually, it begins to fade as soon as the developer looks away.
