kamo-soupbato/projects/gpp/documentation.md

categories	cover	cover_alt	date	description	slug	title
GRS Writing Research	gppc.jpg	someone wants to graduate eh	08/10/2022	The secret plan to graduate	gpp	Graduation Project Proposal

Draft Project Proposal

What do you want to make?

A list of devices to explore software documentation, that is the process of sharing knowledge and making worlds around software.

These instruments will be of various nature: tools, thoughts, anecdotes, excercises, prompts, secrets, ... They will offer entry points to articulate software documentation as a form of care.

Some elements of the list will relate to the materiality and surfaces where documentation is hosted, while others will be more entangled with the actors involved in the process.

To work within the constraints of a structure such as the list will help to think through the complexity of the topic. This complexity will hopefully be preserved and encoded in the relations between different items.

Software documentation is not just a list of technical procedures, but also a matter of providing context and orientate software in the world. In the same way, the list is meant to be a texture where to weave together multiple voices and diverse registry, in order to re-enchant the making of software.

How do you plan to make it?

• Read software documentation
• (manuals, guides, references, tutorial)
• Write software documentation
• Experiment with contents, tone and style
• Focus on the writing process
• Tap into surrounding context
• Meet the actors involved
• Gather impressions and insights
• Order them in a list
• Leave it open for others to contribute
• Find a support where to mount this list

"A list doesn't have to impose a single mode of ordering on what is included in it. Items in the list aren't necessarily responses to the same questions but may hang together in other ways... a list differs from a classification in that it recognizes its incopleteness. It doesn't even need to seek completeness. If someone comes along with something to add to the list, something that emerges as important, this may indeed be added to it."
[John Law and Annemarie Mol, Complexities: Social Studies of Knowledge Practices]

What is your timetable?

• October
  • Define a domain of research.
  • Understand where to ground the project by revisiting first year prototypes.
  • Think about a glossary and possible formats to test some concept in a small scale
  • Experiment writing documentation for XPUB prototypes
• November
  • Experiment writing documentation for project outside XPUB
  • Artistic and commercial ones.
  • Focus on the moments when the documentation happens.
• December
  • Archeology of software documentation.
  • Field research of the current trends in software documentation.
  • Explore different contexts and different coding languages.
• January
  • Follow up on the outcomes of the different hackpacts. Focus on
    1. materiality of the documentation (style, contents, forms),
    2. context around the documentation (actors, timeframe, hosting)
• February
  • Research possible formats for the project outcome.
  • What surface could host this different factes together?
  • Fast daily prototypes
• March
  • Follow up on February daily prototypes and plan for production.
• April
  • Production!
  • First in the form of fast and iterative prototyping, then fine tuning and polishing.
  • Think about graduation exhibition and collective pubblication.

Why do you want to make it?

This project grows out of the frustration of finding myself often trying to deal with bad documented pieces of software. While for sure there is some thrill in understanding how to stitch together these codes, the lack of documentation poses a great hindrance for the participation of diverse knowledges in the making of software.

Who can help you and how?

Relation to previous practice

I'm interested in the development of site-specific software, that is codes that emerge from a community. In this perspective imagine coding as a form of care. Programming as a way to facilitate agency-on and comprehension-of complex systems.

After the work in the past special issues, I'm trying to shift from developing compulsivly to developing in a meaningful way. Meaningful especially in relation to the environment and the other people involved in the process. This means to learn how to balance between different priorities, to understand when to develop something from scratch and when to participate into already existing discourses. It means to learn how to balance between accessibility, susteinability and flexibility.

Relation to a larger context

Software comes from a really specific occidental cultural tradition.
Software tends to priviledge masculine, binary, exploitative and extractive practices.
Software is shrouded in technical obscurity.
Software comes invisible, transparent, neutral.
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 create a context around.

Documentation is a space that interfaces between the code, the user, the developer, and the world. A space with potential to renegotiate and reclaim given margins and entry points. A chance to overwrite what is normalized, and let diverse knowledges and voices participate in the discourse that is software.

Documentation is a way to produce narrations around software. To create a world for the code to inhabit, to give it affordances and stretch what is possible to do or to think with it. Documentation is a space for the political in the software. It's a surface that could host ideas in close contact with code, letting them entangle and shape each other.

Documenting software is a complex practice. It is a process of translation. It requires a lot of time and energy, and it involves many different skills: writing, coding, knowing how to share informations and at which intensity. It is a collaborative practice, an economy of different contributions, a way to let others know where does some code come from, and where it would like to go.

References/bibliography

Start from here

• Fuller, M ed. (2008) Software Studies: A Lexicon, MIT Press
• Ullman, E (2013) Close to the machine: Technophilia and its Discontents, Pushkin Press
• Bridle, J (2022) Ways of Being: Beyond Human Intelligence, Farrar, Straus and Giroux
• Bridle, J (2018) New Dark Age: Technology and the End of the Future, Verso
• Bratton, B H (2016) The Stack: On Software and Sovereignty, MIT Press

And then a list of possible references

• Hayles, N K (2005) My Mother Was a Computer: Digital Subjects and Literary Texts, University of Chicago Press

• Sterling, B (2005) Shaping Things, MIT Press

• Mackenzie, A (2006) Cutting Code; Software and Sociality, International Academic Publisher

• Suchman, L A (1987) Plans and Situated Actions: The Problem of Human-Machine Communication, Cambridge University Press

• Law, J ed. and Mol, A ed. (2002) Complexities: Social Studies of Knowledge Practices, Duke University Press Books Balibar, É (2020) On Universals: Constructing and Deconstructing Community, Fordham University Press

• Cantwell Smith, B (1996) On the Origin of Objects, Bradfor Book

• Knuth, D E (1973) The Art of Computer Programming, Addison-Wesley

• Knuth, D E (1992) Literate Programming, Center for the Study of Language and Information

• Brodie, L (1984) Thinking Forth, Punchy Publising

• Wendy Hui Kyong Chun, "On Software, or the Persistence of Visual Knowledge" (2005) Grey Room. 18

• Lethbridge, Chantelle & Sim, Susan & Singer, Janice. (1999). Software Anthropology: Performing Field Studies in Software Companies.

• Crowston, Kevin and Howison, James, "The Social Structure of Open Source Software Development Teams" (2003). School of Information Studies - Faculty Scholarship. 123.

• Shirky, C (2004) Situated Software

• Catgirl (2022) Comfy Software

• Li, J (2020) Where Did Software Go Wrong?

• wiki.c2.com