--- categories: - GRS - Writing - Research date: 21/09/2022 description: Graduate Research Seminar 2022-2023 slug: grs title: GRS link: - title: Wiki url: https://pzwiki.wdka.nl/mediadesign/Graduate_Seminar_2022-2023 --- ## Session One ### What have you been making? ![sheep rider](sheep_rider.jpg) - 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? ![trolley problem](trolley.jpg) - 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](https://pad.xpub.nl/p/groupdiscussion) 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)](https://blog.jse.li/posts/software/) 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](http://computationalculture.net/software-studies-revisited/), 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](https://en.wikipedia.org/wiki/README) file in order to make the projects more accessible. [Make a README](https://www.makeareadme.com/) 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](http://catb.org/%7Eesr/jargon/html/index.html)) A list of resources: - [Readme Driven Development](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html) - [The Jargon File](http://catb.org/%7Eesr/jargon/html/index.html) - [Origin of "Readme" - Stack Exchange](https://softwareengineering.stackexchange.com/questions/96966/origin-of-readme/97132#97132) 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?) ### 1. [kamo-soupbato](https://git.xpub.nl/kamo/kamo-soupbato)