GRS

Session One

What have you been making?

• Site specific software
• Developing custom tools in order to approach different needs

• Or materialize specific ideas to gain good grip on them.

• Different tools call different grips call different workflows call different outcomes

• Code as a shared practice: from coding alone to coding together

• Interaction between code and the community that surrounds it, how do they shape each other

• Coding as care, not control

• Writing code: balancing between accessibility, susteinability, flexibility.

• Writing after code: how to document and render works accessible, how to partecipate to the public discourse and create communities, how to mantain a project and how to let it go

What do you want to do next?

• Dig more into the difference between:
• coding for oneself (sleep talking),
• coding for others (yelling),

• and coding with others (singing)

• Formalize a methodology for coding as care

• that could be applied to different projects: from personal ones to collective to commercial.

• This could be done by intercepting different ongoing projects (from my artistic practice to freelance works and everything in between) and use them as case studies. Since they involve different kind of public they could provide different insights.

• The idea of the methodology is because of the very nature of Site Specific Software: every context is different, and instead of generalizing one solution for all it would be better to understand some principles to deal with each situation.

Notes from the excercise with Miriam and Aitam

Find the pad here --> Group Discussion

And the trascription of what I said:

Hi, my name is Kamo

- how are you feeling about this year?
i am super excited, it is super exciting to get out of the xpub bubble, to talk to lens based,
i wanna find different degrees of publicness with my practice, it is interesting to make work accessible to people that don't have anything to do with your work
an understanding of what communities i am working with

- what strategies to make it more accessible?
making work interactive, but i am not interested in the idea of participatory art, it always comes with limitations, participation is way more complex than just pressing some buttons, i am interested in the idea of offering software, for this year at some point, i don't see myself focussing on one specific project but multiple alterations applied to different contexts, when i say "software" that's really generic, the chore project is methodology, i always work with the needs of the public, what if i make sth for a client that is already open source, involving the client into thinking this way, inviting to participate on this "openess", i am searching for a position related to certain issues, when you're coding, sustainability, accessibility and flexibility are parts of coding but they don't always have the same priority, for example making code accessible or sustainable for people who will use the code in the future, i would like to write a book about trolley problems, this is sth that interests me how these three pillars work together,

- references?
i learnt about software studies and i would love to dig into this, it is about considering software as a cultural object, to see everything that you see through the software lens as human and non-human beings, how softwares influence our perception of the world, but also zooming in and ask questions like what did control c did to writing? such problems.

- Why is it about the computer?
there is this materiality that could be really alien, it's a different interface to reality

Homework: Hackpact

During the course of 3 weeks develop and execute hands-on:

-   at least experiments, which relate to topics of, what you think will be your grad project.
-   experiment per day
-   no more of 45 minutes for each experiment
-   post the premise, outcome and process of the experiment
-   embrace loss, confusion, dilettance, and serendipity.

1 Hackpact: README.md-fy old repo on git

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

There are 60 repository in my xpub git, most of them without a clear entry point for others. One idea could be to write a daily README file in order to make the projects more accessible. Make a README is a good starting point. Experiment with writing style and approach. Try to understand what is relevant besides technicalities. Could it offer not just a practical bootstrap but also a critical or personal perspective on the tool? Could it enforce some principles or form some habit?

Research

When asked, hackers invariably relate the README convention to the famous scene in Lewis Carroll's Alice's Adventures In Wonderland in which Alice confronts magic munchies labeled “Eat Me” and “Drink Me”. (The Jargon File)

A list of resources:

• Readme Driven Development
• The Jargon File
• Origin of "Readme" - Stack Exchange

Probably not so directly connected but there is this book (which one and where was the reference? maybe in software studies? or in james bridle?)

Hackpact 2

The Padliography is a tool to keep track pad documents. It archives them in a dedicated page in the PZI wiki, through the joined efforts of the MediaWiki API and a Flask app on the Soupboat.

It's as a piece of software made to be offered.

At the moment, even though the project is working, its form is still not ready for the public. It lacks for entry points, and while it has a README.md file, it's not really generous and doesn't cover the basic info that it should document.

The plan is to make it useful for and usable by others:

• Dynamic wiki page
• Init wiki page
• Documentation on how to install an instance of the Padliography
• Generous readme

1st Oct

• Went to the market and bought so much vegetabels that I couldn't lift the ikea bag anymore. Happy with it
• Worked with Supi on the current state of the Workbook to prepare for the M&Ms session of monday.
• Doubts on the backend of the Workbook.

2nd Oct

• Looked into the text editor vim and its tutorial vimtutor. It's a nice hands-on approach to documentation.
• Read a tutorial for setting up Flask and sqlite3. Really a different experience from the vim's one. Much more top-down.
• Branched the Workbook to implement a database system. The original prototype was based on yaml files and nested folders and after a while it was really a convoluted mess. Fractal and funny and ridiculus at some point, for sure painful everytime we had to add some new feature. Even though databases have this ancient technology aura we tried it out and it's way better.
• Maintenability it's critical when a project is meant to be shared.

3rd Oct

• Worked with Supi on the Workbook and presented a demo for the M&Ms session of 3rd Oct. Showcasing a demo it's the best way to understand what is clear and what's not in a project. It also offers different perspectives and alternative entry points.
• Follow-up with Gr and Supi about borders ecology, how a tool defines a community, who's inside and who's outside this community and which forms have the border of this community, where are the entry points, etc.

4th Oct

Refactor of the Padliography to simplify and comment the code. Suggestions from Michael: not a solution && more explicit the idea of creating bridges between technical public and trans*feminist sensibility

6th Oct

Padliography Bis is online, up and running (with some minor bugs but ehh). Wrote the first draft of the README.md file. Find it on git! Now would be nice to organize some moments to share it with XPUB 1 2 3 4 and Lens Based.

some notes for the project:

• plugin pubblishing The plan: republish a text in the form of blender plugin. i.e: excerpts of the text appears in the interface of the 3d editor, maybe even related to specific actions or commands. This could lead to:
• infiltrate communities that is: imagine writing a bespoke plugin following a specific blender tutorial on youtube. this could mean just to sew the text following the process and the commands showed in the tutorial. it's interesting because you have an existing temporality and community to infiltrate, and the work is mimetic. it uses the same propulsion as the original video.
• not a solution, again need to understand what it is if it's not proposed as a solution. how to phrase this condition? if it's not an attempt to solve a problem, what is it? ask for help
• how digital media inform the outcome that is: the real digital nature comes with specific forms. these forms have unexpected and peculiar features that inform and constitute the very same reality we try to critic. Again is mimesis, again is field research, again is a remainder not to fall into classic narration patterns.

7th Oct

• Padliography Bis README.md polishing. Need to write something about how to put a new instance of the padliography online. Could just refer to our experience on the Soupboat.

• Frontend for the workbook! Draft implementation for a couple of pages (Add instrument, Add patch), and text representation of the stored patches.

11th Oct

• Padliography category page on the wiki, with the same contents of the README.md and a list of the archives page.
• Now when the padliography initialize a new archive, it adds the [[category: padliography]] tag, in order to list all the active archives in the category page.
• Next step is: how to make it public?

17th Oct

Public event at Leeszaal: Gersande and me shared a table for discussing our intuitions with the public. It happened because G is working on the surface of the patent and I was super interested in drawing connections between that and the documentation. There were nice suggestions. Simon and Alice suggested to narrow down the audience, for example focusing on the use of documentation in the context of tech-coop. Need to have a look to the notes we collected through the ingenious carbon-copy notation system Grr and Kim developed.

After the event and the discussion Naami sent me this incredible screen that is going directly into the thesis

Thank you Naami!

18th Oct

• Sent some memes to the Piet in order to make the Padliography public (namely: clumsy frog pictures that point to the wiki page of the documentation.

• Organize a public moment in PZI after the break. A monday morning session with the prototyping class? A Friday morning 1 hour worksiop / demo / user test?

25th Oct

• Prepare for the 31 Oct M&Ms

  • Presentation and demo - 10 min

  • Documentation read and review exercise - 10 min

    • Mock product reviews???
    • Roleplay like X_Kitchen (from kim & chae)
    • Your character is a customer / reader of this documentation
    • Mobile form with written feedback + something funny like product picture or reaction
    • title, review, pro / cons + something like a call to participate to the documentation (such as explain the tool with your own words, or similar)

    • Review form: could be interesting to link it to the contents of the documentation (as a way to send feedback to the ones writing the doc) (to create a channel of communication?)

    • (simple form, store reviews in a small db, review different work ??? and an API to integrate the contents with real documentations)

• Think about the documentation for the Workbook with Supi. There is a draft strucutre here workbook documentation.

  • imagine it in a way to coexhist with the aforementioned api ???? wtf did i just wrote aforementioned for real

M&Ms

• Presentation of the Padliography:

  • Sorting table
  • Filtering
  • Add a new pad directly!! (m&ms)
  • Init a new archive
  • Add some pads (modcms, modcms_documentation)
  • Switch between archives

• Documentation of the Padliography

  • wiki

• 10 min roleplay writing exercise

  • read + review as you were on trip advisor or amazon
  • short review + stars ⭐

Find it here:

Documentation roleplay