REALML, Tuesday 11 November 6-7pm CET

For REALML, TITiPI proposes to collectively engage in 'bug reporting'. For over a century, inventors and engineers have used the term `bug’ to refer to mistakes, malfunctions, errors in a system. A 'bug report' in that tradition, documents an intended functionality that fails, or even small mishaps in code, that return errors or stall a technical system, when “something is not working as it was designed to be.”. Bugs and their reports are a fundamental part of learning and making, frustration and re-imagining within the production of a system. They make use of specific platforms and formats (issue trackers) to keep an account of these reports and their progress towards bugs being 'resolved'. As a method, it not only tolerates, but necessarily requires other types of expertise than that of writing code. In this session, we would like to speculate with bug reporting as a method for public engagement with and within the supposedly open space of technology production. How to report bugs that go beyond already existing structures and processes, and what if something is not designed as it should be? What if this system in the making is part of a bigger problem, like reproducing racial capitalism, or stands on the APIs[1] of extractive infrastructures, where do we file the bug? Or, what if the technology in question should be actively undesigned and maybe not exist at all?

18:00 Bug reporting intro

- Welcome, who's here?
- TITiPI http://titipi.org/
- bugreporting?

18:15 three examples of bugreports
-- The long tail of contact tracing (TITiPI, 2020) https://github.com/DP-3T/documents/issues/118
-- Opt Subject: Issues with modifier mechanism, UTS #52 (2016) https://possiblebodies.constantvzw.org/feedback.html + http://www.unicode.org/review/pri321/
-- Bug Report: Tuning to trans*feminist Xystem. Crash (Meltionary, 2020) http://www.meltionary.com/meltries/r.html

How did you try feedback already, if ever? What channel? Did it work/change anything?

18:30 Present two possible bugs to report, ask for possible additions.

1. Amazon Mechanical Turk, Human intelligence task
https://www.mturk.com/worker/help

2. FOLDOUT https://foldout.eu/ + https://possiblebodies.constantvzw.org/inventory/?122
Plantation logic to border control

What other bugs might need reporting?

18:45 We pick one of the above and try to think through the following:

- how would you do it? where do we submit the bug report?
- what are some challenges?
- let's think about ways around it?
- answer the questions for the bug report
- talk about the ways in which problems can be framed, or not

Questions

A format we invite you to engage with in your own style for the bug report writing:

Summary (describe the problem in less than 60 characters)
Component (in which context does this problem exist?)
Version (historical background of the bug)
OS (within which legal~societal~computational~material system is this problem)

Description including (larger detailed summary of the bug)
- "build ID" (which non/humans does this effect most)
- Additional Builds & Platforms (which other contexts are effected? what other positions does this have implications for?)

Steps to reproduce:
- how to trigger the bug 
- actual results (what are the consequences of the bug)
- expected results (what should have happened without the bug)

http://www.meltionary.com/meltries/r.html
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines

19:00 END

























































NOTES

Schedule: https://docs.google.com/spreadsheets/d/1bn0CxkY2DdC7PYTy0EB3B6vUXj7BC46VxZvwbT2l49U/edit#gid=536648324
Overview: https://docs.google.com/document/d/12-DrS4CQSeR7RAXggkKpjO0W3a6xYZsnBVZkvgJqWf8/edit
Session guidelines: https://docs.google.com/document/d/1LCU7FrTIJCMfsDiJyBGZ58KJqm9qDF4HLPm4CxkHmc0/edit

The Institute for Technology in the Public Interest (TITiPI) is a trans-practice organisation initiated by Myriam Aouragh, Seda Gürses, Helen Pritchard and Femke Snelting. Together we convene communities to hold computational infrastructures to account and to create spaces for articulating what technologies in the “public interest” might be when “public interest” is always in-the-making. titipi.org

For REALML, TITiPI proposes to collectively engage in 'bug reporting'. For over a century, inventors and engineers have used the term `bug’ to refer to mistakes, malfunctions, errors in a system. A 'bug report' in that tradition, documents an intended functionality that fails, or even small mishaps in code, that return errors or stall a technical system, when “something is not working as it was designed to be.”. Bugs and their reports are a fundamental part of learning and making, frustration and re-imagining within the production of a system. They make use of specific platforms and formats (issue trackers) to keep an account of these reports and their progress towards bugs being 'resolved'. As a method, it not only tolerates, but necessarily requires other types of expertise than that of writing code. In this session, we would like to speculate with bug reporting as a method for public engagement with and within the supposedly open space of technology production. How to report bugs that go beyond already existing structures and processes, and what if something is not designed as it should be? What if this system in the making is part of a bigger problem, like reproducing racial capitalism, or stands on the APIs[1] of extractive infrastructures, where do we file the bug? Or, what if the technology in question should be actively undesigned and maybe not exist at all?

Bug reporting is an evolving method that is being tested out by artists, activists and independent researchers including The Institute for Technology in the Public Interest.




Seda: The session will present a method for critically engaging technology in production: bug reports. For over a century, inventors and engineers have used the term `bug’ to refer to mistakes, malfunctions, errors in a system. A “bug report” in that tradition documents an intended functionality that fails, or even small mishaps in code, that return errors or stall a technical system. Bugs and their reports are a fundamental part of learning and making, frustration and re-imagining within the production of a system. Yet, what happens when what is being reported on, does not just contain mishaps, but the produced artifact as the problem itself? Or, what if this system in the making is part of a bigger problem, like reproducing racial capitalism, or stands on the APIs[1] of extractive infrastructures, where do we file the bug? Bug reports as a method to engage technology has been worked on by many artists and independent researchers over the last decade and has been adopted into the inventory of The Institute for Technology in the Public Interest. It is an evolving method, a “version” of which we will introduce during the session.

Femke: The Institute for Technology in the Public Interest (TITiPI) is a trans-practice organisation initiated by Myriam Aouragh, Seda Gürses, Helen Pritchard and Femke Snelting. Together we convene communities to hold computational infrastructures to account and to create spaces for articulating what technologies in the “public interest” might be when “public interest” is always in-the-making. We develop tools from feminisms, queer theory, computation, intersectionality, anti-coloniality, disability studies, historical materialism and artistic practice to generate currently inexistant vocabularies, imaginaries and methodologies.

For REALML, TITiPI proposes to collectively engage in 'bug reporting'. Bug reporting is the practice of submitting an account of errors, flaws, and failures alongside technology in development, when “something is not working as it was designed to be.”. It makes use of specific platforms and formats (issue trackers) to keep an account of the bugs and their progress towards being 'resolved'. We want to speculate with it as a method for public engagement operating within the supposedly open space of technology production. As a method, it not only tolerates, but necessarily requires other types of expertise than that of writing code. How to report bugs that go beyond already existing structures and processes, and what if something is not designed as it should be? Or even more importantly, what if it should be actively undesigned and maybe not exist at all?



BUGS TO REPORT

Helen: I'd be interested in doing a food justice ML bugreport - maybe computer vision /industrial farming (I was just looking at all these pictures of men with robotic arms for agritech )-- but don't have anything situated so could be hard

I actually did discuss with Ingmar that we wanted to write a bugreport to 4S/EASST on their use of the machine learning company in the recording of the talks during the conference- and it could be published as an open letter to them - I know this might feel a bit inward academia focused though.

I think its also interesting when its a "tech for good" type of thing - someone using ML for something the think is righting the ethics and us drawing out some bugs in a way to make the system better ( a bit like DP3T)

Covid computer vision things?

Seda: I can ask the student I am working with if she has seen any covid computer vision things.

Mango trees
https://possiblebodies.constantvzw.org/inventory/?122

Reference: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines

the public opinion, private industry and regulatory landscape 
counter existing norms within industry and academic conferences that minimize the lived experiences and interdisciplinary research by practitioners from historically marginalized groups.