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.
275 lines
16 KiB
Markdown
275 lines
16 KiB
Markdown
---
|
|
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
|
|
|
|
<!-- Be prepared to give an account of where you are at with your self-directed research and talk about what you want to achieve this year and what you want to do. Xpub students will talk about the work they have been doing on the Special Issues (individually and collectively). All students will be asked to consider what possibilities they wish to explore in the coming year.
|
|
|
|
Think concretely about what you want to make this year, how you are going to make it and why you are going to make it. Consider: What possibilities are open to you? (It is understood that making a final project is a process and things will change as you work on it). What material have you written (for previous presentations, descriptions of work , assignments for last year's methods class, the methods of annotation you developed &c) which you can use? Review the written feedback from tutors you got from previous assessments and have it available for reference during the first session. -->
|
|
|
|
### 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?)
|
|
|
|
## Draft Project Proposal
|
|
|
|
### What do you want to make?
|
|
|
|
A methodology for software development as a form of care.
|
|
Research how writing software changes depending on the context and actors involved.
|
|
Bring the specificity of three different case studies: coding for oneself, coding for others, coding together with others.
|
|
How different nuances of these three settings can inform and resonate one with the other?
|
|
|
|
### How do you plan to make it?
|
|
|
|
The plan is to focus on three parallel 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.
|
|
Not all these projects need to start from scratch. This year could be the chance to inject some awareness and forms of care in already ongoing works.
|
|
|
|
Developing for myself could happen in the context of [Object Oriented Choreography](../ooc-summer-session/), a long-term contemporary dance research with VR. What would it mean to bring XPUB forms of care into that work? How could tools developed for personal needs participate to a broader discourse?
|
|
|
|
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 rinegotiate 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](../workbook/) with supi, the ilizarov projects with gr, etc ) or intercepting some external realities' need to craft together some piece of site-specific software.
|
|
|
|
### What is your timetable?
|
|
|
|
**October**
|
|
Define practically a method for the methodology: think about protocols and possible formats for graduation project outcome.
|
|
Define the premises in which to ground the three projects by revisiting first year projects. Draw a political compass of software as care.
|
|
Get in touch with different communities for case study 2 and 3.
|
|
|
|
**November**
|
|
Work on OOC, preparing for December performance at NaO Festival, Milan.
|
|
Develop context and prep-works for case study 2 and 3: plan timetable.
|
|
Get in touch with key figures to interview for research.
|
|
|
|
**December**
|
|
OOC performance and follow-up about findings for the methodology.
|
|
|
|
**January**
|
|
Start working on case study 2.
|
|
Start working on case study 3.
|
|
|
|
**February**
|
|
Work on one case study.
|
|
Update protocols and possible formats for graduation project outcome.
|
|
|
|
**March**
|
|
Work on the other case study.
|
|
Update protocols and possible formats for graduation project outcome.
|
|
|
|
**April**
|
|
Follow-up about findings for the methodology.
|
|
Production for methodology outcome.
|
|
|
|
**May**
|
|
Production for methodology outcome.
|
|
Production for graduation exhibition.
|
|
|
|
**June**
|
|
Graduation exhibition.
|
|
Party
|
|
|
|
**July**
|
|
Siesta
|
|
|
|
### Why do you want to make it?
|
|
|
|
<!--
|
|
developement is really specific technical community (white cis male eheehhe)
|
|
a lot of violence, status quo, reinforced in the industr, competition,
|
|
control, frame the world in a form that you can control and act on from a really occidental point of view, colonialistic, extractive form
|
|
i would like to research on the question: can we do it in another way? giving back something and not only take
|
|
when you're using a tool you can learn the world throught the use of it, the difference is: can i use the scissors to cut a piece of paper and make a notebook or kill someone? -->
|
|
|
|
This is a list of current trends that the software industry enforces and naturalize.
|
|
|
|
Software comes from a really specific occidental cultural tradition.
|
|
Software tends to priviledge masculine, binary, exploitative and extractive practices.
|
|
Software is shrouded in technical obscurity.
|
|
Software comes invisible, transparent, neutral.
|
|
Software models the world in order to control it.
|
|
|
|
To make software means not only to write code, but also to take a stance regarding this trends.
|
|
With this project the intention is to situate my practice within ethical yet sustainable boundaries.
|
|
|
|
### Who can help you and how?
|
|
|
|
I would like to interview some artists with programming-related practices to get some glimpse of their workflows.
|
|
I'm thinking for example to Nathan Sinigalia, Ian Cheng, Nicolas Maigret.
|
|
I want to ask to Ariella Vidach A.i.E.P. how working with technology changed in the past 30 years.
|
|
I'm interested in the workflow of radical studios such as Open Source Publishing but also more commercial ones like Forensic Architecture and Studio Moniker.
|
|
For sure it would be interesting to get in touch with someone mantaining open source projects such as Paged.js, P5Js, vvvv, or more unconventional ones.
|
|
Some interesting things could emerge from field research directly in git repositories, issues and wikis.
|
|
|
|
The practical aspect depends on the second and third case studies. There are some communities I would like to work with: Pietre Parlanti is a non-profit association that works with the recovery of old routes and cultural heritage in Liguria, Italy. I'm already in touch with them for [Frana Futura](../frana-futura/), the documentary I'm working on with Sofia, Elena and Micalis.
|
|
|
|
### Relation to previous practice
|
|
|
|
### Relation to a larger context
|
|
|
|
### References/bibliography
|
|
|
|
- software studies - ed. matthew fuller
|
|
- close to the machine - ellen ulman
|
|
- ways of being - james bridle
|
|
- new dark age - james bridle
|
|
- cuttling code - software and society - adrian mackenzie
|
|
- gay robot noises - comfy software
|
|
- kent beck - wiki.c2.com
|
|
- extreme software & SCRUM
|
|
- simon yuill
|
|
|
|
## 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
|
|
- infiltrate communities
|
|
- not a solution, again
|
|
- how digital media inform the outcome
|