kamo-soupbato

kamo

kamo-soupbato

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.

18 KiB

Raw Blame History Unescape Escape

How to deal with complexity

complex systems and ways to access complexity.
different form of intelligence: the word, the body, the emotion.
how do these different kinds of making sense of the world inhabit complexity?
relations between complex systems and their context
tools to access complexity, tools to interface complexity
coding as a form of care instead of control

Tools to access, make meaning and gain agency over complexity

critical tooling
community software
Site specific software
software for trigger dynamics in communities
Creating rituals/dynamics within a specific topic
Systems that helps make meaning together
How system and software are offered, introduced and presented to a community
How to model software and tool around and within specific contexts

Community software
Lee Felsenstein & Community Memory
The Mother of All Demos
The Software Arts
The Democratic Surround: Multimedia and American Liberalism from World War II to the Psychedelic Sixties (2013)
From Counterculture to Cyberculture: Stewart Brand, the Whole Earth Network and the Rise of Digital Utopianism (2006)
Radical Software
Videobase and Jean Rouch (especially Chronique d'un été) and the video to create community are example of rituals informed by technology?
The three SI as case studies. Try to formulate them in terms of critical tooling - community software - site specific software
Eventual Consistency, the case of Y.js and Joseph Gentle
How tools and communities shape each other

Tool to think with

"The crisis can be solved only if we learn to invert the present deep structure of tools; if we give people tools that guarantee their right to work with high, independent efficiency, thus simultaneously eliminating the need for either slaves or masters and enhancing each person’s range of freedom. People need new tool to work with rather than tools that “work" for them." Industrialization and Conviviality (Ivan Illich)
Tool to work with / tool to think with
On misconvenience - Silvio Lorusso @workshoppino xpub
The Piet ? What's the difference between sharing the tools developed in the context of xpub (si16, si17, xbranch, soup aggregator, karaoke, aggregator, wiki api etc) & propose a collab tailored on the need of the piet ? (both things can cohexist)

Documentation as a surface

How tools are offered to a community through documentation
Dig more into this idea of offering - what does it mean?
Documentation as an interface to complexity ? A way to navigate the unwkown
The documentation system
Soft software
Ways of sharing knowledge
Documentation as a platform?
What should be fixed and what should be flexible in a documentation ?
How to take care of a documentation system ?
Possible topic of research for applying to the server residency at avantwhatever.net/
Knowledge system vs screening of dataset - Ron Morrison - Decoding space: Liquid infrastructures
Ron Morrison - Gap between the digits

Community Software repris

El rumiante apuesta por un ejercicio de **invención política** que es colectivo, siempre. Procura darse, para sí y su comunidad, herramientas, y entiende que estas herramientas no son algo a lo que se llega, sino que están en constante construcción.
Epistemologia Rumiante, from Camilo & Maria 's workshop
Nicolas Malevé, “The cat sits on the bed”, Pedagogies of vision in human and machine learning.
bell hooks, Theory as a liberatory practice (in: Teaching to transgress)

Tool grip

Tool as a way to access reality, to gain grip onto the world.

There is something different in how we do create tool for ourselves, and how we do create tool for others.

See GRS for an intro about this.

Coding contingencies

Code is always addressed to someone. [...] We do not write code for our computers, but rather we write it for humans to read and use. Jesse Li (2020)

Coding is not just production of software, but also production of knowledge. A dialogue between human and more-than-human actors. The guestlist of this conference of the bits is often compiled by chance: the choice of a particular programming language, the coding style, the development environment and ecosystem, the infrastructure that runs the code, and so on, are the result of specific contingencies.

These contingencies are situated in precise contexts, and these contexts are different one from another. Programming is not just sharing code, but sharing context. It's to provide a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script. That's the reason why even if source code, even when obscure and obfuscated, speaks for itself, it cannot always cast light around its surroundings. To make place for the code turns to be a necessary act of care in the process of sharing knowledge.

Code ages fast. Because it moves at lightspeed into fiber optic cables, its tempo flows at a total different pace compared to the velocity of our cultural daily life.

wip

Software as care DUMP

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?

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?

There are three main nodes in the graph of this project. Writing software, taking care, and staying low.

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.

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

Developing for myself could happen in the context of Object Oriented Choreography, 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 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]

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.

Coding Contingencies

These contingencies are situated in precise contexts, and these contexts are different one from another. Programming is not just sharing code, but sharing context. Programming means to provide a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script. That's the reason why even if source code, even when obfuscated, speaks for itself, it cannot always cast light around its surroundings.

If software illuminates an unknown, it does so through an unknowable (software) (Wendy Hui Kyong Chun, 2022)

To make place for code turns to be a necessary act of care in the process of sharing knowledge. This does not mean to constrain the usage of some piece of software, or provide opinionated solutions or tutorials, but rather letting others know where does this code come from, and where it would like to go.

“Our machines should be non-binary, decentralized and unknowing.” (James Bridle. “Ways of Being.”)

“To think again or anew, we need to re-enchant our tools.” (James Bridle. “New Dark Age.”)

The ordinary professional programmer addresses himself to the problem to be solved, whereas the compulsive programmer sees the problem mainly as an opportunity to interact with the computer. (Joseph Weizenbaum)

Code is always addressed to someone. [...] We do not write code for our computers, but rather we write it for humans to read and use. Jesse Li (2020)

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.

Brainstorming fr the projekt

An extensible toolkit to explore the ecology of software documentation: its materiality, the actors involved and the economy that surrounds it.
A set of tools and practices that focus on software documentation as an interface between the code, the user, the developer, the community, and the world.
A handbook with a strong attention on the economy of different knowledges present in software documentation. How this exchange of resources could make place for different voices.
A collection of small devices to assist and stimulate the documentation process, with cue and gently reminders that software documentation is a form of care.
A series of writing prompts to experiment with software documentation as a generative device to keep thinking through code from different and marginal 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.
A (loose, habitable, extensible) map to orientate around what does it mean to make software besides just writing code.
A writing machine to build worlds around software.

About the hackpacts

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]

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.

[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.

What does it mean to offer it to someone else? How to talk the same language in different contexts? How to be clear without oversimplifying?

[Hackpact 3 - Write documentation & focus on the process of writing]

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.

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 the process?

[Hackpact 4 - Write documentation & focus on the surrounding context]

Expand the research to tap into ongoing projects outside XPUB, such as freelance work and parallel research like Object Oriented Choreography, a performative 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 issues in subtle ways. Offer entry points and escape routes from the automatic outcomes proposed by tech solutionism. Offer alternatives to sedimented roles in the care of software.

[hackpact 5 - Write documentation & focus on who is writing it]

What are the relations between documentation and the community around a software?

Experiment with versioning.
Try to have several instances of the same documentation.
Try to question who gets to write and who gets to read 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?

[hackpact 6 7 8 - Towards final project]

Collect and organize the outcomes from the different hackpacts.
Trace trends and synthetize common and diverting aspects.
Research for a surface that could host this different facets.
How can it inhabit the usual places where documentation is hosted?

I'm trying to learn how to approach complexity as an environment. How to stay complex without forcing the result being complicated, that is how to reduce complexity without loosing value. This usually happens when diverse actors participate in the process, when ideas and practices traverse through the software without being totally framed into it.

18 KiB Raw Blame History Unescape Escape