thumb
km0 2 years ago
parent a5e4d2994f
commit 4d66abaad3

@ -86,12 +86,30 @@ During the course of 3 weeks develop and execute hands-on:
- embrace loss, confusion, dilettance, and serendipity.
```
## 1 Hackpact:
## 1 Hackpact: README.md-fy old repo on git
### 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/)
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 kickstart but also a critical perspective on the tool?
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.
What does it mean though to return to old projects?
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)

Loading…
Cancel
Save