Grgr project proposal: Difference between revisions

From XPUB & Lens-Based wiki
 
Line 66: Line 66:


<u>'''3 📊 Table of death'''</u>
<u>'''3 📊 Table of death'''</u>
[[File:Dashboardroom.jpg|center|frameless|400x400px]]


An open database to keep track of the research, collect and organize findings. These can include the collection of references, tools and whatever material used/encountered during the whole process.  And it could be as simple as a 2-columns table with links and their descriptions.
An open database to keep track of the research, collect and organize findings. These can include the collection of references, tools and whatever material used/encountered during the whole process.  And it could be as simple as a 2-columns table with links and their descriptions.

Latest revision as of 00:08, 20 January 2023

1. What do you want to make?

A System Requirement Specification (SRS) for bureaucratic infrastructures of collective work. A SRS is a document that describe a set of strict requirements and use cases for a system (or software) to function, including specifications about use cases and reasons. (See thesis outline for more information on SRS >> About the SRS as mode of address)

I imagine the SRS to be a trigger to engage in conversation with different self-organized cultural initiatives, organizations, or spaces and research how their bureaucratic infrastructure would support, limit or shape their work. And viceversa, how their ways of organizing brought them to the choice or the creation of specific bureaucratic or administrative tools.

By bureaucratic infrastructure, I mean the plethora of softwares, tools and methods used to communicate, organize, planning budget, and doing taxes (f.e. zulip, slack, wecan, nextcloud, calendar.... etc), but also the physical technological infrustructure in which these softwares and methods live. 

The graduation project could be distributed on 3 pathaways:

  * 1 📜 the SRS itself: 
  * 2  🔦 Boiler inspections
  * 3 📊 Table of death

2. How do you want to make it?

1 📜 the SRS itself:

A collection of assessment criteria to evaluate bureaucratic infrastructure of collaborative work, but also use cases that link to existing or invented tools, methods, hacks, guidelines to organize and sustain collective work through administration and bureaucracy.

It's the starting point and the arrival of an iterative process of dialogue and admin-to-admin review. Meaning that I imagine there will be a field research in which I will engage in a dialogue with a series of self-organized cultural initiative in order to explore their "administrative body".

The field research will take the form of regular boiler controls, that will help to review and add onto the list of criteria and use cases of the specification.

Steps:

      * draft first demo release
      * contact target cultural organizations
      * conduct boiler inspection
      * dump new information in the table of death
      * review demo
      * restart


2 🔦 Boiler inspections

boiler_inspection


It's a virtual or IRL site inspection of different bureaucratic infrastructures for collaborative work.

The session will take place in form of a facilitated and recorded conversation with members of different self-organized cultural organizations.

The methods to facilitate and the format of the recording is something that can vary depending on the type of *Boiler *to be inspected

Steps:


SimpleBoilerInspectionDiagram.jpg
    1. preparation
      * preparation of initial set of questions to facilitate the inspections
      * choose self-organized organizations to inspect
      * preparation of more specific set of questions
      * organize the inspection
    2. the inspection
      * facilitated discussion
    3. after inspection
      * dump the results into the Table of Death 
      * review the SRS
    4. restart


3 📊 Table of death

Dashboardroom.jpg

An open database to keep track of the research, collect and organize findings. These can include the collection of references, tools and whatever material used/encountered during the whole process. And it could be as simple as a 2-columns table with links and their descriptions.

I'm currently calling it database, because I'm already prototyping some exercises in the format of a database, and because it would be perfect to exercise and embody bureaucratic administration. But ideally the form could change along the process.

In this stage of proposal, I think it's useful to define that this element exists and that is a database, in order to visualize the kind of support I will create for myself to track the research.

In a second moment the same support could be presented as a sort of appendix to provide extra context and references to the SRS.

Steps:

      * more exercises and prototypes with databases
      * prototype structure of the database
      * test the platform in which the database will live (which git? which server?)
      * undergo boiler inspection
      * editorial moment for recorded documentation: which material to keep? how to organize it?
      * review of the database format: shall it be structured differently? is it handy to track the research?
      * restart from "undergo boiler inspection"
      * decide on final format and function of the database.

3. What is your timetable

* 1 📜 the SRS itself:

* 2 🔦 Boiler inspections

* 3 📊 Table of death

Timetable2.jpg


***november***

      * ~~18th deadline thesis outline and project proposal~~
      * research on different organizational bureaucratic tools
      * writing >> observations and first chapter thesis
      * research >> specifications and bureaucratic tools for collective organizing, working, publishing 
      * reading >> collect, select and plan further readings
      * 24th field trip ---> International Clinic (Het nieuwe instituute)
      * []28th Public Moment at Buitenboel:[] mini zine publication 

***december***

      * []2nd: deadline first chapter thesis[]
      * research >> on bureaucratic tools.
      * []12th-13th: assessments[]
      * reading >> build reading routine
      * prototype >>  📊 first prototype

***january***

      * reading routine
      * writing >> first 📜 SRS prototype/draft 
          * field trip ---> business station 
          * field trip ---> research station
          * field trip ---> organize other field trips
      * contact julie from Paged.js
      * start organize 🔦  boiler inspections 
      * prototype >> collect - organize feedbacks and new info into 📊 

***february***

      * reading routine
      * writing >> new 📜 srs final draft + observations
      * []17th: deadline first thesis draft[]
      * 🔦  boiler inspections 
      * 📊 dump

***march***

      * reading routine, but also stop reading too much
      * 🔦  boiler inspections 
      * 📊 dump
      * writing >> 📜 srs final draft + reflections
      * 17th deadline second thesis draft

***april***

      * writing >> 📜 final SRS  + questions for further research
      * 14th: final deadline thesis
      * prototype >> 📊 decide on the final use
      * graduation publication

***may***

      * graduation publication production

***june***

      * publication production
      * 12th-13th assessments


4. Why do you want to make it?

More general reasons:

During the time in XPUB, I recognized and enjoyed the role of editor and caretaker in the relation to collective work, and this is something that I would like to explore keeping in mind some questions I received during the past assessment: "how do you look at the role of administration in relation to collective work? How do you look at the role of administration as an editor-curator?"

To create meaning and context around publishing practices, in order to legitimize amatorial knowledge, safe learning environments, and collaborative work. An earlier step, though, needs to be taken in consideration: how to sustain whatever publishing practice in the first place? How to be realistic about the resources available, funding plans, and working conditions? To embody these questions in my practice, I would like to learn how to facilitate dialogue and negotiate collaborative work, and also how to do my taxes.


Particularly about the SRS:

As I explain in the thesis outline > I'd like to expose the content of the research to open modifications, revisions, and collaborative negotiation, using the format of a SRS would allow me to render the criteria elaborated to assess bureaucratic infrastructures of collective work, and at the same time provide a structure in which discussion can happen through requests for change.

It can be a way to stimulate critique towards naturalized bureaucratic practices that clashes with a creative and collective process, and suggest alternative use-values of the instruments that support these practices.



5. Who can help you and how?

📜 the SRS itself, tips and how to:

      * Julie Blanc and Julien Taquet >> Julie, in particular, wrote an extensive specification within the paged.js project
      * Business station
      * Research station

🔦 Boiler inspections, organizations/collectives/spaces I could start asking about their bureaucratic infrastructures:

      * Varia (Manetta, Cristina, Lidia, ... )
      * Constant (Michael)
      * Platform BK (Koen Bartijn and Sepp Eckenhaussen)
      * qujOchÖ (Davide Bevilacqua)
      * Autonomic (Calix, Luke)
      * Autonomous Lab (Florian Cramer)
      * TiTiPi (Femke Snelting)
      * Feral Business Research Network (Kate Rich and Angela Piccini)

📊 Table of death

      * All my xpub2 colleagues and tutors, for tips, how-to, organization, references and feedback



6. Relation to previous practice

My previous practice is very heterogeneous including different media and formats, but looking back I can see some patterns I was following intuitively, and that I would like to explore with sharper intentions now. These include on one hand collective ways of documenting, mapping, researching on a local/situated level through ad hoc tools or manipulation of existing technologies; on the other hand questions around how to use this as emancipatory material to shape and give value to a collective knowledge and living.

During the last year, this translated into being super excited about using an API as publishing platform, turning a post-it block into a lootbox, caretaking and proposing structures (often in the form of a tool or an interface or re-enactment of something); or smuggling different techniques or questions from other domains.

In parallel, since 2 years now, I've been involved in the process of visualizing, formulating a narration and mapping the ecosystem of stakeholders of a diabetes program in The Hague. In this process I'm learning to problematize the way Dutch health-institutions would meet marginalized communities within a constellation of delicate, low-threshold, dynamic relations through a variety of events and activities.

ah-ah moment:

In a recent art residency in Cagliari (IT), Chae and I started a project about crunchy food. We mocked the language of academia and scientific research to justify and conduct a collection of data around crunchiness. This would include a series of intimate dialogue-sessions with people about their memories and imaginary of crunchiness, in an attempt to define the perfect crunch.

At the same time we started to display our own timeschedule to invite the public to our data collection, to present the overall project and to debrief the final outcome.

During this residency Chae and I started to reflect on how to make public the hidden intimate and pleasurable moments of our stay in Cagliari, in which in fact bits of our work were still present. We decided, then, to be upfront about them, and to use our schedule as a prop to talk about how human dimension and reciprocal care can be brought back into the dry organization of our project, on one hand. And on the other hand, how to manifest a consensual negotiation between work-related activity and care/affect-based relations?

After those consideration and events I started to play around with the name of the project: from *Critical and intimate evaluation of crunchiness*, to *Critical and intimate evaluation of bureaucracy... *



schedule_debrief

IMG: the above mentioned presentation of the working schedule



7. Relation to a larger context

Working conditions in cultural production >> Platform BK

During the Special Issue #16, I had the chance to get to know the work of Platform BK. I would like to connect their work to my broader interest towards technology infrastructures. I'm curious about how their stances on improving cultural producers' working conditions on the level of policy making would translate into a reflection on bureaucratic infrastructures for collective work.


Feral Businesses Research Network >> RADMIN

A festival of Radical Administration. It's the main inspiration and starting point from which I began collecting references, and ideas for the graduation project. The realm of administration and bureaucracy is see as creative space and meaningful work.


"Caring infrastructures, infrastructures of care"

The topic of care in relation to technology is something that I've been cherishing for long. It is also declared and strongly explored in projects like The Pirate Care Project, TiTiPi, The Care Collective



8. References/bibliography

starting from:

  • Graeber D.(2015), The Utopia of rules. On technology, stupidity, and the secret joy of bureaucracy
  • Olson, H.A. (1998)*. Mapping Beyond Dewey’s Boundaries: Constructing ClassificatorySpace for’ Marginalized Knowledge Domains*
  • The care Collective (2020), *The care manifesto: the politics of interdependence*
  • The Institute for Technology In the Public Interest (2022), Infrastructural Interactions: Survival, Resistance and Radical Care
  • | Depressive realism an interview with Lauren Berlant