@ -40,3 +40,70 @@ There are several approaches for making worlds around software. Here are some ke
These labels are open and loose, overlapping and not mutually exclusive, temporary and on the move. They are meant to change, to expire fast, and going bad even faster: they require continuous treatments and repeated efforts. That's why I'm naming them all after the _re_ prefix: to aknowledge their being in progress, second hand again, already contaminated. Borrowed by friends and foes, that had borrowed themselves from someone else. One should diffidate of these categories because they're instable. Nonetheless, they offer ways to visualize different strategies to create worlds around software.
<!-- This section is focused the relation between code and documentation practices, in the form of coding contingencies, political aesthetic and worlding. These terms come from different directions and with different focuses, but all of them offer ways to create context around code. -->
```note
it could be nice to have a small glossary / way to situate / elaborate on these terms:
(or even better to use them to organize the chapter and the examples)
coding contingencies context around code, either intentional or contingent
political aesthetic political choices that inform technical choices
worlding aesthetic practices that create narrations around code
would it make sense then to move here the coding contingencies section from the intro?
There seems to be a risk in reducing sociality around software to a conflict between "friends and foes": a risk to reproduce forms of exclusion and violence typical of the IT world. To just swap good and bad, and offer clean solutions.
```placeholder
Try instead to apply Chantal Mouffle's concept of agonistic politics to software development, intended as struggle between different hegemonic projects. But maybe is to much of a stretch
```
```placeholder
How can documentation create new spaces around code? Where new spaces means spaces for who are excluded.
```
```placeholder
Think about the works around queerying technologies, from Zach Blass to Trans\*feminist servers, to Queerying UNIX, to 360 degrees of proximity, the Queer motto API.
```
```placeholder
Think about projects related to accessibility, and space built by and for people with diverse ability. Alt-text poetry could be a good starting point.
```
```placeholder
Think about the efforts to create safe spaces to learn.
@ -65,13 +65,67 @@ errors, service availability, consent and refusal, tokenism, all the terms neutr
2
```note
the concept of service could be link with 360 degree of proximity
```
code documentation is knowledge transmission, traditionally passed from top to bottom as in comunicating vessels
there are other ways however: where knowledge can be cultivated horizontally, emergent and reinforced by processes of collective learning, where transmission is not intended just one-way
feminists federating
fluid processes - not purely technical architecture, but affective infrastructure
process of collective learning and knowledge transmission 360 degrees of proximities
```note
would be nice to hear more about this new project from Mara - aka try send a mail tomorrow ?
```
#### from alt-text as poetry to the discussion about accessibility in p5js to the soupboat
alt-text as poetry is a project by Bojana Coklyat and Shannon Finnegan
published as a website and other flexible formats it's an ode to the alt attribute in html image tag
alt-text is an essential part of web accessibility. it offers text descriptions which makes visual content accessible to people who are blind, low vision, or have certain cognitive disabilities
```note
rewrite or quote?
```
> Alt-text is an essential part of web accessibility. It is a system of text descriptions built into websites, which makes visual content accessible to people who are blind, low vision, or have certain cognitive disabilities. Alt-text has existed since the 1990s, but it is often over-looked altogether or understood solely through the lens of compliance. The resulting alt-text is often written in a reluctant, perfunctory style, but it has tremendous expressive potential. __This workbook re-frames alt-text as a type of poetry__ and provides exercises to practice writing it. __We don‘t just want alt-text users to be able to access visual content on the internet, we want them to feel a sense of belonging in digital spaces__
(from alt text as poetry)
the project could be seen as a whole piece of documentation dedicated to a single html attribute.
it activates a ways of thinking that goes beyond the technical, dealing more with the programmers and the users, than with the underlying machine.
HTML doesn't really complain about missing alt attributes, and that lead through the years to neglect its value for accessibility
here code documentation is used to encourage certain practices
not only to re frame alt-text as a type of poetry, but also to create a sense of belonging in digital space for people usually ignored by visual culture
---
#### from the discussion about accessibility in p5js to alt-text as poetry
in the discussions around the development of p5.js once i read an interesting thread about having in every script a mandatory `describeElement()` function offering a text description of the running sketch (so are called p5.js scripts). p5js graphics are based on the html canvas element, that instead of organizing its contents in more or less semantic way as html does, presents only a matrices of pixels. this is a big hustle for screen readers and accessibility. the `describeElement()` function is the same as the one of alt attribute, describing what's happening on screen.
the interesting part of the discussion was about this function to be mandatory in order to make the script run
and it is interesting to think how it would be reflected in the library documentation:
to which kinds of world would a choice like that openn?
not relegating them to the background, but instead making them as important as all the other (technical) choices that were made when desining the language
#### create / claim new spaces for participation, validate participation
as for now it's not happened. open source projects like this one are collective effort, and to take big decisions with breaking changes like this one is always complex and slow
---
from my side: last year when developing my space on the soupboat i decided not to display images if they don't come with alt text
decision like these aren't really different from how a type system work, or how the syntax of a certain function is written. everything has been decided by someone. these decisions can create or claim new and safe spaces for participating to programming practice, or validate this participation
create / claim new spaces for participation, validate participation
```note
àhah ugly writing is difficult at the beginning but then gets funny
```
### aesthetic practices - hello worlding
@ -97,7 +151,6 @@ To re-enchant code then means not only to _find & replace_ terms throughout the
#### uxn ecosystem: re reading esolangs, plan-9, and virtual machines through the ecological lens
A good example is the work of documentation around the Uxn ecosystem, a personal computing stack initiated by the 100 Rabbits collective.
@ -149,72 +202,3 @@ Soon and Cox prepared these lessons for students enrolled in a design institutio
[ fade out towards outro ]
```note
it could be nice to have a small glossary / way to situate / elaborate on these terms:
(or even better to use them to organize the chapter and the examples)
coding contingencies context around code, either intentional or contingent
political aesthetic political choices that inform technical choices
worlding aesthetic practices that create narrations around code
would it make sense then to move here the coding contingencies section from the intro?
There seems to be a risk in reducing sociality around software to a conflict between "friends and foes": a risk to reproduce forms of exclusion and violence typical of the IT world. To just swap good and bad, and offer clean solutions.
```placeholder
Try instead to apply Chantal Mouffle's concept of agonistic politics to software development, intended as struggle between different hegemonic projects. But maybe is to much of a stretch
```
```placeholder
How can documentation create new spaces around code? Where new spaces means spaces for who are excluded.
```
```placeholder
Think about the works around queerying technologies, from Zach Blass to Trans\*feminist servers, to Queerying UNIX, to 360 degrees of proximity, the Queer motto API.
```
```placeholder
Think about projects related to accessibility, and space built by and for people with diverse ability. Alt-text poetry could be a good starting point.
```
```placeholder
Think about the efforts to create safe spaces to learn.
