smaller and bigger edits everywhere (@ccl: catched a food flow :---))

content/Section 1 - Digital Infrapuncture/1-introduction.md

@@ -9,32 +9,25 @@ Informed by the work of scholar Nowviskie (Nowviskie 2015)[^Nowviskie], Verhoeve
 
 In her presentation, she describes digital infrastructures according to their:
 
-* capacity to create the conditions of possibility for connection
+* capacity to create the **conditions of possibility for connection**
-* their capacity for repair (Jackson, 2014)[^Jackson]
+* their capacity for **repair** (Jackson, 2014)[^Jackson]
-* and their capacity to bring things (back) together
+* and their capacity to **bring things (back) together**
 
 ![A screenshot of the last slide from Verhoeven's presentation.](/images/slide.png)
 
-If we understand an infrastructure as a relational device, or in other words as a technology that bring things (back) together, we can start to critical read them through these features. 
+If we understand an infrastructure as a relational device -- or in other words -- as a technology that bring things (back) together, we critically enquire where do fail in doing this.
 
-Who is an infrastructure bringing together?
+What are examples of infrastructures that do *not* bring things together anymore? 
 
-How are these connections constructed and formatted?
+How does an infrastructure connect? And how are these connections constructed and formatted? 
 
-What are the conditions and possibilities for connection they provide? 
+Who is an infrastructure bringing together? And who *not*? What are the conditions and possibilities for connection they provide? Where do they *not* connect and concequently exclude people? 
 
-Where do they not connect and concequently exclude people? 
+And, most importantly, *who* can actually intervene in the design of infrastructures? And *how*?
 
-[something to bridge to the punctuating part]
-
-And who can actually intervene in these processes?
-
-<br>
 <br>
-<br>
-
 
-# Links & Further readings
+# Footnotes & Further readings
 
 [^DigitalInfrapuncture]: Verhoeven, Deb. "Opening Keynote: Identifying the point of it all: Towards a Model of 'Digital Infrapuncture'" *Digital Humanities at Oxford Summer School* (2016) [https://podcasts.ox.ac.uk/opening-keynote-identifying-point-it-all-towards-model-digital-infrapuncture](https://podcasts.ox.ac.uk/opening-keynote-identifying-point-it-all-towards-model-digital-infrapuncture)
 

content/Section 1 - Digital Infrapuncture/2-question-1.md

@@ -3,6 +3,10 @@ Slug: 02-s1-question-1
 Date: 2020-11-01 12:01
 Summary: A video contribution by Deb Verhoeven.
 
+Deb Verhoeven first introduced the term *infrapuncture* in 2016 at a Digital Humanities conference in Oxford. In her talk she gives the example of the Greek and Italian cinemas that appeared in Melbourne before the invention of the video tape and the influence they have had over the influx and organisation of the Italian and Greek immigrants living in Australia at the time. Her research concluded that these small cinemas that only screened subtitled Italian and Greek movies led to an increase in migrant population from those areas. Similarly, the shutting down of a cinema coincided with the dispersion of the immigrant community in the neighbourhood.
+
+In the following video contributions, Deb Verhoeven will unpack the term *infrapunctures*. She will explore how it is a useful departure point for infrastructural change that is benificial for the communities who uses them.
+
 <video controls>
 	<source src="https://vvvvvvaria.org/archive/2018-02-16-Extratonality/dennis-not-supercut-yet.mp4" type="video/mp4">
 </video>

content/Section 2 - Stress Points In Digital Infrastructures/1-what-types-of-bots-are-there.md

@@ -1,7 +1,6 @@
 Title: Introduction: Programmable Infrastructures
 Slug: 01-s2-introduction
 Date: 2020-11-01 12:00
-Summary: <Short summary here>
+Summary: What are Programmable Infrastructures?
 
-==What are Programmable Infrastructures==
+How are digital infrastructures different from other infrastructures? Seda Gürses in collaboration with Roel Dobbe and Martha Poon have formulated a distinct category: *programmable infrastructures*.
-How are digital infrastructures different from other infrastructures? Seda Gürses in collaboration with Roel Dobbe and Martha Poon have formulated a distinct category that 

content/Section 2 - Stress Points In Digital Infrastructures/2-question-1.md

@@ -1,4 +1,4 @@
-Title: Question 1: Where do you locate causes of infrastructural stress?
+Title: Question 1: What are programmable infrastructures? 
 Slug: 02-s2-question-1
 Date: 2020-11-01 12:01
 Summary: A video contribution by Seda Gürses.

content/Section 2 - Stress Points In Digital Infrastructures/3-question-2.md

@@ -1,4 +1,4 @@
-Title: Question 2: Who or what is involved in creating these moments of stress?
+Title: Question 2: What are elements that shape (or are shaped by) programmable infrastructures?
 Slug: 03-s2-question-2
 Date: 2020-11-01 12:02
 Summary: A video contribution by Seda Gürses.

content/Section 2 - Stress Points In Digital Infrastructures/4-question-3.md

@@ -1,4 +1,4 @@
-Title: Question 3: Who or what is affected by these moments of stress?
+Title: Question 3: How can they be made to serve a "public interest"?
 Slug: 04-s2-question-3
 Date: 2020-11-01 12:03
 Summary: A video contribution by Seda Gürses.

content/Section 2 - Stress Points In Digital Infrastructures/5-question-4.md

@@ -1,4 +1,4 @@
-Title: Question 4: What forms of automated agents play a role in the transformation/change of infrastructures? 
+Title: Question 4: Who can be involved in the making of these infrastructures? 
 Slug: 05-s2-question-4
 Date: 2020-11-01 12:04
 Summary: A video contribution by Seda Gürses.

content/Section 2 - Stress Points In Digital Infrastructures/6-question-5.md

@@ -1,4 +1,4 @@
-Title: QUESTION 5
+Title: QUESTION 5: What interventions are possible in programmable infrastructures? 
 Slug: 06-s2-question-5
 Date: 2020-11-01 12:05
 Summary: A video contribution by Seda Gürses.

content/Section 3 - Bots/1-introduction.md

@@ -1,33 +1,5 @@
-Title: Introduction: Bot Logic
+Title: Introduction: Bots
 Slug: 01-s3-introduction
 Date: 2020-11-01 12:00
-Summary: Could bots represent a 
+Summary: 
-
-## Bots as infrapunctures
-
-Infrapuncture is a comely term at a moment in time when there is a lot of discussion around the political roles of automated agents in digital infrastructures. Before we move any further, perhaps a short definition of bots is necessary. When we say bots, we refer to code that automatises certain behaviours and which often acts as an interface between platform and human users.
-
-Many online communities engage with bots, for example the editor community of English Wikipedia, which consists of both humans and bots. The interactions between them go beyond the maintenance of Wikipedia. Instead, affective relations are formed wherein the bots are anthropomorphised. So writing a bot implies not only to understand the API (Application Programming Inferface) of the platform, what determines the possibilities of interaction, but also the social norms established within the community of editors and users of Wikipedia.
-
-And that's of course just one example. Bots act differently depending on the platform on which they are running.
-
-## Bot logic
-
-What kind of puncturing logics might bots enable in digital platforms?
-
-Bot logic is phrased as a response to platform logic, which Jonas Andersson Schwarz describes as "digital platforms enacting a twofold logic of micro-level technocentric control and macro-level geopolitical domination, while at the same time having a range of generative outcomes, arising between these two levels". 
-
-'Bot logic' refers to the situational effect of bots upon a socio-technical ecology and their potential to infiltrate and co-exist with server-side conditions. Perhaps we can move our attention to these few points. When referring to platform logic in the points below, we refer to commercial infrastructures, not federated and free software platforms such as those present in the Fediverse, which have a different kind of dynamics[^theses].
-
-* Where platform logic accumulates, bot logic disperses
-	* On commercial platforms, the engagement of users equals economic value that is translated through data capture and organisation. Metadata is extracted from users that then through pattern matching can be used to target users for advertisements. While bots can and do participate in this economy, they can also enable its sabotage. In the case of buying bot followers, this can be a means to generate noise in the collected dataset and blur the perception of the user as a set of behaviours that the platform has.
-* Where platform logic centralises, bot logic fragments
-	* Platforms such as Twitter or Facebook use a centralised system, in the sense that the servers on which our information is stored are owned by their company. Bots, on the other hand, do not require a lot of computational power in order to run. They can be simply run from the computers of the persons who wrote the code themselves. In fact, bots really point to the materiality of the structures on which they run, as researcher Stuart Geiger also points out when he talks about 'bespoke code' as code that extends or transforms the operations of software platforms, but "runs on top of or alongside existing systems instead of being more directly integrated into and run on software-side codebases".
-* Where platform logic creates distance between user and infrastructure, bot logic develops an intimate knowledge of the platform
-	* If we consider means of communication as means of production (Williams, 2005), there is a certain alienation that happens on commercial centralised platforms, where the user has no stake in the development of the material conditions of the platform on which they communicate. From this point of view, the making of bots implies a closeness to the platform that is indicated through the understanding of both the sociological and technical systems that determine the usership of a platform. In order to code a bot, you need to know what kind of actions are allowed and how the bot would be received by the community.
-* Where platform logic reinforces habitual behaviour, bot logic encourages new habit formation
-	* If we think about a commercial platform as a structure or surface on which actions can take place, these actions are often predefined by the affordances of the platform. However, as was mentioned in the beginning, bots are the automation of certain actions and behaviours. To be able to define these behaviours as a user can mean an alteration of the socialities embedded in a platform.
-
-All of these points were written with commercial platforms in mind, however, exciting developments are happening in federated platforms such as Mastodon, where users are part of defining features and possibilities of interaction. There, the norms of the platform and the way they are codified into the technical structure are more often revised and reformulated together with the user base. This in itself creates a different space for bots, which are still active contributors in the way sociality is imagined on these platforms. However, on platforms like Mastodon, bots don't only comply to the terms of services of the API but also to the code of conduct, for example.
-
 

content/Section 3 - Bots/3-bot-logic.md

@@ -1,6 +0,0 @@
-Title: Bot Logic
-Slug: 03-s3-bot-logic
-Date: 2020-11-01 12:03
-Summary: <Short summary here>
-
-

content/Section 6 - Critical Interventions Through Bots (exercise)/1-introduction.md

@@ -3,13 +3,13 @@ Slug: 01-s6-step-1
 Date: 2020-11-01 12:00
 Summary: Start of the bot-making excercise.
 
-In this section we will make a bot. 🤖
+In this last section of the module we will make a bot. 🤖
 
-We will use the dialog writing exercise and transform it into a bot ([in case you haven't done it yet, you could first go through this section](/category/http://localhost:8000/category/section-5-infrapunctural-imaginaries-exercise.html)).
+We will use the dialog writing exercise and transform it into a bot ([in case you haven't done it yet, it is recommended to go through this section first](/category/http://localhost:8000/category/section-5-infrapunctural-imaginaries-exercise.html)).
 
-Before we dive into that, we will first look into the **materiality of bots**: How are they operating? What code is needed to make a bot? And how does a bot connect to an infrastructure, both in a technical and dialogical way?
+Before we dive into bot-making, we will first look into the **materiality of bots**: How do they operate? What code is needed to make a bot? And how does a bot connect to an infrastructure, both in a technical and dialogical way?
 
-Then we will explore bots from a computational and technical point of view. We will go through a couple of basic features of **programming logic**, such as loops, if/else statements and variables. It will help us to get closer to mechanisms in which these automated agents are written.
+Then we will explore bots from a computational and technical point of view. We will go through a couple of basic features of **programming logic**, such as loops, if/else statements and variables. It will help us to get a better understanding of the technical mechanisms behind these automated agents.
 
 After that, we will look at the code of an **example bot**, to study how other bot-makers write and operate them.
 

content/Section 6 - Critical Interventions Through Bots (exercise)/2-materiality-of-bots.md

@@ -3,57 +3,67 @@ Slug: 02-s6-step-2
 Date: 2020-11-01 12:01
 Summary: Code, API's and background processes.
 
-Talking about the materiality of bots might sound a bit funny at first. It is crucial though to closely look at *how* and *where* a bot operates, in order to imagine in what kind of way they can intervene in an infrastructure. As we learned from the section *Bot Logic*, making a bot both includes studying its technical mechanisms and the platform, network of infrastructure it will operate within. 
+Talking about the materiality of bots might sound a bit funny at first. It is crucial though to closely look at *how* and *where* a bot operates, in order to imagine in what kind of ways they can intervene in an infrastructure. To do this, we will study the digital materiality of bots.
 
-To unpack the materiality of bots, we can have a closer look at three features of a bot-making process:
+We use the term *materiality* by following Johanna Drucker's definition of *performative materiality*[^drucker]:
 
-1. code
+> “Performative materialtiy suggests that what something is has to be understood in terms of what it does, how it works within machinic, systemic, and cultural domains.”
-2. API's
+
-3. background processes
+
+<!-- As we learned from the section *Bot Logic*: bot-making includes not only a study of technical mechanisms, it also includes studying the norms, values and communicative habits of an infrastructure.  -->
+
+The materiality of bots can be unpacked through three technical ingredients of a bot-making process:
+
+1. **code**
+2. **API's**
+3. **background processes**
 
 ### Code
 
-The first feature will not come as a surprise: **code**. If we look at the digital materiality of a bot, we can say that it is a script: an executable file that sits on your computer or on a server. Code is used to describe how the bot makes a connection, what behaviour it has and when it comes into action.
+The first ingredient will not come as a surprise: **code**. 
 
-There are a whole range of programming languages that a bot-maker can use to make a bot. The most popular ones are Python and Javascript. The choice for a specific language is often based on the preference of the programmer, it is a bit like picking your favorite flavour. However, the choice for a programming language can also be based on the availability of a library around an API. 
+If we look at the digital materiality of a bot, we can say that a bot is a script: an executable file that sits on your computer or on a server. Code is used to describe *how* the bot makes a connection, *what* function it has and *when* it comes into action.
+
+There are a whole range of programming languages that a bot-maker can use to make a bot. Popular programming languages are Python and Javascript. The choice for a specific language is often based on the preference of the programmer, it is a bit like picking your favorite flavour or color. However, the choice for a programming language can also be based on the availability of a so called *library*: a friendly wrapper that enables a programmer to interact with an API. 
 
 ### API's
 
 If we talk about the relationship between platform and bots, we cannot escape talking about the **API**. 
 
-The term *API* is an acronym for Application Programming Interface. It is an code-based interface between the programmer and a platform, such as Wikipedia, Reddit, Whatsapp, Twitter or Mastodon. Not all platforms have an API, it's a decision of the owner of the platform to make one. Every API is therfor different and comes with different constraints or rules.
+The term API is an acronym for Application Programming Interface. It is an code-based interface between the programmer and a platform, such as Wikipedia, Reddit, Whatsapp, Twitter or Mastodon. Not all communication infrastructures have an API, it's a decision of the owner of the infrastructure to make one. Every API is therefor different and each one comes with different rules and constraints.
 
-Taina Bucher[^bucher] defines an API as:
+Taina Bucher[^bucher] defines an API as an infrastructural device that is shaped (and shaping) many different things:
 
 > “Among other things, web APIs encompass: a physicality in terms of the corporeal landscape of infrastructure and technology, through to the economic logics at work (i.e. business models, ownership, licencing of the APIs), functions and services (i.e. access to data), practices of users (i.e. forms of labor, play and collaboration), discursive formations (i.e. statements, knowledge, ideas), rules and norms (i.e. design principles, terms of service, technical standards), as well as social imaginaries and desires.”
 
-An API is a set of rules that applications use to communicate with each other. This (apparently) neutral conception is in reality a very complex conglomerate of imaginaries, whether technological, economical or societal. 
+When looking at API's from a technical perspective, we see a set of rules that applications use to communicate with each other. This (apparently) neutral conception is in reality a very complex conglomerate of imaginaries, whether technological, economical or societal. 
 
 Essentially does the API determine how the platform developers imagine it will be used by other developers, revealing a relationship of imbalanced power. It welcomes interventions as an opportunity to expand the functionalities beyond what the original developers might have imagined. On centralized infrastructures this often results into generating more economical value in the end.
 
-So to sum up: a bot is written in code and uses an API to connect to an infrastructure.
+So to sum up: a bot is written in **code** and uses an **API** to interact with an infrastructure.
 
 ### Background processes
 
-In order to run the bot, we need one more last feature: a so called **process**.
+To run the bot, we need one more last ingredient: a so called **process**.
 
-A *process* is nothing more then a term to refer to the act of putting the bot into action. In the most simple version, this can be done by running a script from your own computer. In a more complex version, you could upload your script to a server and run it from there *continuously*.
+A *process* is nothing more then a term to refer to the act of putting the bot into action. In the most simple version, this can be done by running a script from your own computer. In a more complex version, you could upload your script to a server and run it from there continuously as a **background process**.
 
 Why would you run a bot continuously? 
 
-As bots usually operate over a long period of time, you might not want to run them from your own computer, as this means that you need to keep your computer on for a long period of time (like a year or as long you want to have your but running). 
+As bots usually operate over a long period of time, you might not want to run them from your own computer, as this means that you need to keep your computer on for a long period of time (imagine you want to keep a bot running for a year!). 
 
-Instead, bot-makers often run their bots from a server instead. There they can run the bot as a *process*, which allows them to turn it into a background activity. As processes bots can be stopped, started or restarted. Their status can be checked (to see if a bot is still running for example) and logfiles can be accessed.
+Instead, bot-makers often run their bots from a server. There they can run the bot as a *background process*, which allows them to continuously run a bot without their own precense. Processes can be stopped, started or restarted at any time with simple commands. Their status can be checked (to see if a bot is still running for example) and logfiles can be accessed.
 
-These three features (*code*, *API's* and *background processes*) give us an understanding of what the digital materiality of a bot is. 
+These three ingredients (*code*, *API's* and *background processes*) provide insight into the digital materiality of bots.
+
+In the next page we will further unpack the material implications of code, by zooming into the features and constraints of *programming logic*. 
 
-<br>
-<br>
 <br>
 
 ## Footnotes
 
-[^bucher]: Taina Bucher, Objects of Intense Feeling: The Case of the Twitter API
+[^bucher]: Taina Bucher (?) *Objects of Intense Feeling: The Case of the Twitter API*
+[^drucker]: Johanna Drucker (2013) *Performative Materiality and Theoretical Approaches to Interface*, <http://digitalhumanities.org//dhq/vol/7/1/000143/000143.html>
 
 
 

content/Section 6 - Critical Interventions Through Bots (exercise)/3-programming-logic.md

@@ -2,3 +2,37 @@ Title: Programming Logic
 Slug: 03-s6-step-3
 Date: 2020-11-01 12:02
 Summary: Loops, if/else statements, variables and more.
+
+> People, things, events are "programmed", one speaks of "inputs" and "outputs", of feedback loops, variables, parameters, processes, and so on, until eventually all contact with concrete situations is abstracted away.[^weizenbaum]
+
+As bots are written in code, they are based on the features and constraints of *programming logic*.
+
+To unpack this term, we will speak about:
+
+* loops
+* if/else statements
+* variables
+
+### Loops
+
+A loop ...
+
+```
+for n in range(5):
+	print('ha' * n)
+
+> ha
+> haha
+> hahaha
+> hahahaha
+> hahahahaha
+```
+
+### if/else statements
+
+### Variables
+
+
+## Footnotes
+
+[^weizenbaum]: Joseph Weizenbaum (1976), *Computer Power and Human Reason*

content/pages/start.md

@@ -5,17 +5,24 @@ Slug: start
 
 Welcome to the online module *Bots as Digital Infrapunctures*. :-)
 
-Inspired by the potential of "digital infrapuncture", a term coined by researcher Deb Verhoeven, this module brings bots and infrastructure together as *infrapunctures*. "Infrapuncture" is a portmanteau word which conflates "infrastructure" and "acupuncture", referring to small-scale interventions that have a catalytic effect on the whole. This module explores what role bots can have as infrastructural "stress relievers".
+Inspired by the potential of *digital infrapuncture*, a term coined by researcher Deb Verhoeven, this module brings bots and infrastructure together as *infrapunctures*. *Infrapuncture* is a portmanteau word which conflates *infrastructure* and *acupuncture*, referring to small-scale interventions that have a catalytic effect on the whole. This module explores what role bots can have as infrastructural stress relievers.
-
-The module contains a set of exercises, short programming logic introductions and video recordings of invited speakers. You will encounter examples of bots, bot makers and theoretical reflections. 
 
 # Goals
 
-By the end of this course you will have analyzed the norms and values embedded in a specific digital environment where group formation and group communication happens (e.g. micro-blogging platforms, groupchats, discussion forums, mailinglists, etc). 
+The goal of this online module is to foster *tool criticism thinking* (e.g. the skills and practices for critically engaging with the norms and values of our computational tools and infrastructures). The module consists of readings, videos and exercises that help you analyze and reflect on how infrastructural agency, impact or power is shaped, structured and performed.
+
+By the end of the module you will have:
 
-Through readings, introductions and exercises, you will have reflected on how infrastructural agency, impact or power is shaped and structured. You will have identified moments of tension and friction within digital infrastructures and considered how a bot could intervene to release stress.
+<!-- check this list ... not sure if they speak back to the content of the video's -->
 
-You can go through this module at your own speed. No subscription is required, you can simply start by clicking on the "next" button and follow the instructions. 
+- identified some of the norms and values of a digital communication infrastructures 
+- signaled a particular tension (or rather hurt) that emerges from these norms and values 
+- studied different kind of examples of communicative and artistic bots
+- learned how bots can be activating agents by identifying (?) hurt 
+- proposed a bot that could potentially resolve (resolve? spack back to? engage with?) this hurt
+- evaluated the implications of bot-making and bot interventions
+
+You can go through this module at your own speed. No subscription is required, you can simply start by clicking on the "start" button in each section and follow the instructions.
 
 You will need approximately 4 hours to go through this whole module. 
 
@@ -23,6 +30,8 @@ You will need approximately 4 hours to go through this whole module.
 
 This module is written by Cristina Cochior and Manetta Berends who are both part of [Varia](https://varia.zone/en/), a member-based organisation in the South of Rotterdam that works on/with everyday technology. 
 
-The module is developed in the context of the *Tool Criticism* course at the [University of Utrecht](https://datafiedsociety.nl/research/) in collaboration with [Creative Coding Utrecht](https://creativecodingutrecht.nl/). 
+The module is developed in the context of the *Tool Criticism* course at the [Utrecht University](https://datafiedsociety.nl/research/) in collaboration with [Creative Coding Utrecht](https://creativecodingutrecht.nl/). 
+
+This work is kindly supported by the Utrecht University and (© Varia 2020) published under the XXX license. 
 
-The work is funded by the University of Utrecht and published in November 2020.
+The sources of this module can be found here: <https://git.vvvvvvaria.org/mb/bots-as-digital-infrapunctures>