@ -79,58 +79,25 @@ One example is the paradigm of constant availability of the server. Behind every
!!! note ""
maybe more examples from the documentation of queer motto api
!!! note "SI16 API"
- SI16 API where ????
- horizontal and vernacular
- after queer motto api
- after screenless office because of docstrings? or maybe use docstrings here?
### Situated docs
### Federated docs
To inject context in software is required to operate at different scales. Within both public and private dimensions, with technical and social frameworks. During a workshop for example, people meet face to face. Here togetherness can glue technicalities together, questioning reproduction of knowledge and its power dynamics. (See for example _Feminists Federating_, mara karagianni, ooooo, nate wessalowski, vo ezn in Toward a Minor Tech - A peer reviewed Newspaper vol 12, 2023) (Note that the opposite effect is also true, with technicalities as paratext conditioning how people are together)
!!! note "service and proximity"
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
To inject context in software is required to operate at different scales. Within both public and private dimensions, with technical and social frameworks. During a workshop for example, people meet face to face. Here togetherness can glue technicalities together, questioning reproduction of knowledge and its power dynamics.
- documentation practices and politics of participation
- from wishlist for transfeminist servers to queer motto api to 360 degrees
- relation between wishlist and code documentation
Code documentation is knowledge trasmission, traditionally conceived as a vertical and centralized practice, where who is teaching and who is learning stand at radically diametrically opposite sides of the spectrum, in well defined roles. From this perspective only the _real programmer_, the expert that detains a phantomatical _foundational knowledge_, is allowed to share wisdom and document code.
- about 360
- where does it come from?
- how does it work? already started?
- does it involve also writing code documentation?
As argumented by Kit Kuksenok during the activation of their workshop _Sharing Programming Knowledge_ at Varia (Rotterdam), things are more fluid than that: everyone is sometimes a learner, and sometimes a teacher. Each role brings valuable insights to its counterpart, and taking it into account open the way for other pedagogical and organizational tactics for sharing knowledge. One example are collective learning moments, situations where code documentation is at the same time active practice and shared surface, wobbly ok but more horizontal.
- situated code documentation? iterative? always the same? always different? depends on the context?
_360 degrees of proximities_ is a project emerging from a network of feminist servers, addressing the problem of invisible labor tipically associated with maintainance of digital infrastructure.
pls use our nicknames
estragon
e.zn
After a sucessfull setup of a self-hosted Peertube instance, a federated platform for sharing video contents, the group started questioning aspect regarding the maintenance of the system. Instead of centralizing the service in a self-exploitative scenario, they decided to redistribute it on the network working together with other feminist and queer communities, empowering them to build their own video platforms autonomously, but in a joint effort where different knowledges meet. On one hand the know-how about installation and configuration of Peertube brought by the _360_ team, and on the other site-specific knowledge of the hosting server.
Here is where the interesting friction of situated documentation arises: how to share knowledge about something deeply situated with other contexts? How to remain legible and accessible, while at the same time preserving specific and characterstic choices? Usually documentation doesn't take into account the messiness of coding contingencies, where multiple software cohexist in the same server and configurations conflict with each other, or are installed with different setups. Collective learning moments can close the gap between an ideal setup described in the docs and a real-world, situated one.
