No edit summary |
(re-drafted into, quite cut back, hope its okay.) |
||
| Line 2: | Line 2: | ||
==== '''Praxis Doubling''' ====<!-- Do we need a sub-heading - or something like Praxis Doubling through documentation? I feel like for SEO type shit why might want to flag the docs element up for in the title. I think it is for it being transcluded into the book tbh -G --><!-- +1 for the previous comment about flagging the chapter's focus on documentation in the title. 'Praxis doubling: affective documentation'? --><!-- COMMENTS FROM SHAPE: The question of semi-plain language is very interesting. I am wondering how you relate it with the theoretical language used in the article. For instance, the chapter alternates between rather simple sentences and sentences such as "a shaping of users and experts through flexings of soft bodies towards determinate hard machines and systems." that require more familiarity with academic prose. Personnally I like this alternance, but I am wondering what kind of threshold it creates. In fact this is a question that can be extended to the whole book. In sedimented norms, I wonder if there can be some room for the diversity of documentation practices. In my experience, there are indeed docs that are designed with a certain form of economy in mind, but there are others such as personal install notes, user journeys, documented wikis that are more hospitable and collaborative. And sometimes extraordinarily generous. In Servpub Docs In-Praxis, it reminds me of the proliferating nature of the Debian documentation effort as portrayed by Christophe Lazaro https://www.constantvzw.org/verlag/spip.php?page=article&id_article=119&mot_filtre=8&id_lang=0# I can't wait to read "more on the details of the workshopping" as anounced in Activating the docs. Exciting! Perhaps come back more explicitly on the idea of praxis doubling throughout the text as it is anounced at the begining but not really used as such in the text. --> | ==== '''Praxis Doubling''' ====<!-- Do we need a sub-heading - or something like Praxis Doubling through documentation? I feel like for SEO type shit why might want to flag the docs element up for in the title. I think it is for it being transcluded into the book tbh -G --><!-- +1 for the previous comment about flagging the chapter's focus on documentation in the title. 'Praxis doubling: affective documentation'? --><!-- COMMENTS FROM SHAPE: The question of semi-plain language is very interesting. I am wondering how you relate it with the theoretical language used in the article. For instance, the chapter alternates between rather simple sentences and sentences such as "a shaping of users and experts through flexings of soft bodies towards determinate hard machines and systems." that require more familiarity with academic prose. Personnally I like this alternance, but I am wondering what kind of threshold it creates. In fact this is a question that can be extended to the whole book. In sedimented norms, I wonder if there can be some room for the diversity of documentation practices. In my experience, there are indeed docs that are designed with a certain form of economy in mind, but there are others such as personal install notes, user journeys, documented wikis that are more hospitable and collaborative. And sometimes extraordinarily generous. In Servpub Docs In-Praxis, it reminds me of the proliferating nature of the Debian documentation effort as portrayed by Christophe Lazaro https://www.constantvzw.org/verlag/spip.php?page=article&id_article=119&mot_filtre=8&id_lang=0# I can't wait to read "more on the details of the workshopping" as anounced in Activating the docs. Exciting! Perhaps come back more explicitly on the idea of praxis doubling throughout the text as it is anounced at the begining but not really used as such in the text. --> | ||
<big>'''''=='''''</big> | |||
Praxis doubling is itself a plural. The _ing on doubling is a process ongoing, a verb and an action that is multiplied through different orientations and approaches. By doubling praxis we aim to coalesce together, seduce and mutually shape feminist network praxises with critical access praxises. In this dance aiming to feel out how both of these approaches to bringing theory into collective action can not only make room for more accessible technical praxis, but also for their matters to become more frictious and disputed.<!-- poetry too much? | |||
Praxis doubling is itself a plural. The _ing on doubling is a process ongoing, a verb and an action that is | |||
- I agree I'm not sure exactly what's meant here. Could we move to end of para for clarity and adjust to 'Praxis doubling is plural.' as this is sounds nice and is defined a bit by what comes before. K | - I agree I'm not sure exactly what's meant here. Could we move to end of para for clarity and adjust to 'Praxis doubling is plural.' as this is sounds nice and is defined a bit by what comes before. K | ||
Gotta love it tho. . . . | Gotta love it tho. . . . | ||
--> Praxis itself being the combination of practice and theory, of code and conduct, and of docs and protocols. Praxis doubling we offer how bringing together different praxis makes room for them to permeate one anothers, to diviate actions and can animate relations otherwise.<!-- I added this sentence. This might not be the best definition of praxis doubling, but i think we need a plain definition of what we mean by the term - it's there already but its a bit opaque atm. - K --> | |||
To make-sense <!-- Some of these words, like "feel out" and "rub up against" and "wiggle room" can be confusing because they are discursive terms and plain-language phrases at the same time, but don't necessarily mean the same thing. Maybe we footnote some clarification? -->of these technical network relations together In-grid has built up a debugging practice around technical docs. Technical documentation is a resource that explains processes and practices of technical infrastructures.<!-- This footnote could be incorporated into the main text in order to flag the chapter's focus on documentation a bit more thoroughly in the introduction. -->This collective debugging praxis came about when we came in touch with Serpub's table of feminist network praxis, and brought with us our own background of collective access praxis. By disobediently making room at this collective table for these methods we aimed not only to make room to make-sense of our misffiting with the inherited figures and imaginaires of network infrastructures and their technical docs, but so that this room for misfitting can disorient dialogues towards forming our own collective counter imaginaries and figures that can reshape their limits, and what is backgrounded within their praxis. | |||
====== methods section? ====== | |||
I am wondering if we have a quick methods para to talk about disobedient action research or maybe this [https://revisioncentre.ca/misfits-meet-art-and-technology misfts/cripping text] <- this basically says making sense of frictions and misfitting in determined relations is a way to subjectivley situate and deviate actions from their plans . . . <!-- i am wondering if this praxis doubling practice is something emerged through the practice of the servpub project, or writing this book and try to reflect on this? | |||
(if we think about this servpub book is about making a book, i feel i miss this link of how this chapter plays out) --> | (if we think about this servpub book is about making a book, i feel i miss this link of how this chapter plays out) --> | ||
====== Background to | ====== Background to In-grids Docs Praxis ====== | ||
To describe why the Servpub docs look and work the way they do, we must first (briefly) explain how in-grid as a collective works. Specifically, the processes that facilitate that/our work. The number of in-grid members hovers around 13-15 active members at any given time. Of that group, smaller groups form around specific projects and streams of work, usually around 4-6 members focusing on a project at a time [^1]<!-- is this meant to be a ref? -->. | To describe why the Servpub docs look and work the way they do, we must first (briefly) explain how in-grid as a collective works. Specifically, the processes that facilitate that/our work. The number of in-grid members hovers around 13-15 active members at any given time. Of that group, smaller groups form around specific projects and streams of work, usually around 4-6 members focusing on a project at a time [^1]<!-- is this meant to be a ref? -->. Most of us are fractional and/or precarious workers, so even when a project garners the interest of enough people to make it feasible, we still face the material obstacle of meeting everyones capacity. This includes allowing for last minute drop-outs from meetings to make space for shifts in work or other commitments, as well as caring for those that turn up after months out and want to join back in. | ||
Most of us are fractional and/or precarious workers, so even when a project | |||
We also | We are also quite promiscous as a collective and enjoy collaborating with a range of individuals beyond In-grid's already intersectional members. For us this doesn't dilute who we are but brings in a wide rage of expertise and perspectives that we feels outweighs an experienced or expert individual. So while everyone has the opportunity to contribute to our ways of collaborating, we agreed early on to aim to not silo off our different skills into roles, determined expertise and isolated/ing processes but to make room for them to be shaped by bodies inside and outside of our collective. Not only did this oriente our collective practices towards skill and knowedge sharing in practice, but it also made room for projects to be more accesible to collaborators, where otherwise there might be social, technical or capacitiy based barriers. We have found that even though caring for this wide range of perspectices, practices and politics take a lot more labor, it offers room for these approaches to multiply, for them to more than double, and for us to unfold situated praxis from specific projects and relations, such as the docs and workshops we share here. | ||
'''''<big>Abundent notes, better make some room for them</big>''''' <!-- not a heading me just breaking it up + trying to have fun. Can remove - G --> | |||
During the Servpub project, we adopted an exhaustive note-taking process, not only to document meetings, but to create how-to guides and informal educational resources and relatable diagrams to inform everyone as much as possible about the contextual and technical details within each project.<!-- I'd like to see more technical details on note-taking and documentation. What software is used for this and why? How do you diagram? Is there a method to the arrangement and structure of notes? How is note-taking labour distributed? --> These practices stem for In-grid from the copious notes we make every meeting we have, even back to when we began working together in 2020. Many of our earlier materials are misplaced, mislabled or duplicated as we have been trying over these years to feel out a way of keeping records outside of big tech, and in a way that is accessible to our members however entangled they are. For the Servpub project, and before we had the wiki installed, we made notes together on etherpads hosted by a scattering of other collectives and organisations<!-- add ref with links to pads, just in my writing flow now - G -->. These pads held our notes from submeetings, workshops, conversations, and saved chat logs. Slowly ufolding from this scattering of pads and notes we started to makes sense of what these infrastructures, technical practices and their knowledges were to us and how we desired to shape them.<!-- Again, I'd love to know where these notes are kept and what considerations went into the current structure of community notes. --> | |||
<!-- what is this refers to? do you mean not every one needs to know how to code as contribute to write the docs? -->These notes overflowed from the working sessions we had with other feminist server collectives such as Systerserver, Varia, and CC, where they shared with In-grid their practices and politics around setting up and maintaining these types of network infrastructures. Several interested in-grid members did not have the capacity to attend these initial training moments, and so to keep them updated we began this project's infinite-scroll-like pages of notes, code blocks and annotations. These notes included references to documentation from other collaborating groups, and to "official" documentation provided by the makers of the softwares we used. We felt it necessary to record the practical steps of the process, alongside more affective notes and asides to eachother. <!-- This idea of 'affective documentation' is really interesting and it'd be good to see it expanded a little to show what this looks like in practice, how it is done in the ServPub documentation, and perhaps some of the challenges of blending technical detail with emotional nuance. -->This allowed us to be ourselves, and express moments of connection to and around documentation that could otherwise be isolated and dispassionate. | |||
Over time it became apparent that our unweildly scattering of notes and Servpub's particular setup, needed it's own technical docs to make room for these technical practices to takes shape from the backgrounds, relations and politics around this infrastructure. We go on to share how through these critical access informed docs made room to question how their inherited formats for sharing technical knowledges were sedimented within configurations to dictate bodies, practices and matters into determinate infrastructures, roles and relations. By doubling these technical praxis of documentation with critical access praxis we made room to access the relations, figures and politics iherited from their configurations, and make-sense for ourselves of how these normalizing relations misfitt our devious collective bodies. In making room for frictious misfitting, feeling the pressure and inflexibilty of configurations as to imagine how we desire to be collectivley (dis)oriented otherwise. | |||
<!-- this is a good paragraph to dig into the issue of current doc landscape, but wonder if this could be expanded --> | <!-- this is a good paragraph to dig into the issue of current doc landscape, but wonder if this could be expanded --> | ||
<!-- alt finishing para to one above, just a suggestion, but might be good to loop it back to core approach, instead of giving deets on practices. --> | <!-- alt finishing para to one above, just a suggestion, but might be good to loop it back to core approach, instead of giving deets on practices. --><!-- look forward to read further and see how you address these docs in this way --> | ||
====== Sedimented Norms<!-- this section needs way more doing to it -->====== | ====== Sedimented Norms<!-- this section needs way more doing to it -->====== | ||
Revision as of 11:36, 21 November 2025
<unicode>⟀⋒⌘</unicode>
Praxis Doubling
==
Praxis doubling is itself a plural. The _ing on doubling is a process ongoing, a verb and an action that is multiplied through different orientations and approaches. By doubling praxis we aim to coalesce together, seduce and mutually shape feminist network praxises with critical access praxises. In this dance aiming to feel out how both of these approaches to bringing theory into collective action can not only make room for more accessible technical praxis, but also for their matters to become more frictious and disputed. Praxis itself being the combination of practice and theory, of code and conduct, and of docs and protocols. Praxis doubling we offer how bringing together different praxis makes room for them to permeate one anothers, to diviate actions and can animate relations otherwise.
To make-sense of these technical network relations together In-grid has built up a debugging practice around technical docs. Technical documentation is a resource that explains processes and practices of technical infrastructures.This collective debugging praxis came about when we came in touch with Serpub's table of feminist network praxis, and brought with us our own background of collective access praxis. By disobediently making room at this collective table for these methods we aimed not only to make room to make-sense of our misffiting with the inherited figures and imaginaires of network infrastructures and their technical docs, but so that this room for misfitting can disorient dialogues towards forming our own collective counter imaginaries and figures that can reshape their limits, and what is backgrounded within their praxis.
methods section?
I am wondering if we have a quick methods para to talk about disobedient action research or maybe this misfts/cripping text <- this basically says making sense of frictions and misfitting in determined relations is a way to subjectivley situate and deviate actions from their plans . . .
Background to In-grids Docs Praxis
To describe why the Servpub docs look and work the way they do, we must first (briefly) explain how in-grid as a collective works. Specifically, the processes that facilitate that/our work. The number of in-grid members hovers around 13-15 active members at any given time. Of that group, smaller groups form around specific projects and streams of work, usually around 4-6 members focusing on a project at a time [^1]. Most of us are fractional and/or precarious workers, so even when a project garners the interest of enough people to make it feasible, we still face the material obstacle of meeting everyones capacity. This includes allowing for last minute drop-outs from meetings to make space for shifts in work or other commitments, as well as caring for those that turn up after months out and want to join back in.
We are also quite promiscous as a collective and enjoy collaborating with a range of individuals beyond In-grid's already intersectional members. For us this doesn't dilute who we are but brings in a wide rage of expertise and perspectives that we feels outweighs an experienced or expert individual. So while everyone has the opportunity to contribute to our ways of collaborating, we agreed early on to aim to not silo off our different skills into roles, determined expertise and isolated/ing processes but to make room for them to be shaped by bodies inside and outside of our collective. Not only did this oriente our collective practices towards skill and knowedge sharing in practice, but it also made room for projects to be more accesible to collaborators, where otherwise there might be social, technical or capacitiy based barriers. We have found that even though caring for this wide range of perspectices, practices and politics take a lot more labor, it offers room for these approaches to multiply, for them to more than double, and for us to unfold situated praxis from specific projects and relations, such as the docs and workshops we share here.
Abundent notes, better make some room for them
During the Servpub project, we adopted an exhaustive note-taking process, not only to document meetings, but to create how-to guides and informal educational resources and relatable diagrams to inform everyone as much as possible about the contextual and technical details within each project. These practices stem for In-grid from the copious notes we make every meeting we have, even back to when we began working together in 2020. Many of our earlier materials are misplaced, mislabled or duplicated as we have been trying over these years to feel out a way of keeping records outside of big tech, and in a way that is accessible to our members however entangled they are. For the Servpub project, and before we had the wiki installed, we made notes together on etherpads hosted by a scattering of other collectives and organisations. These pads held our notes from submeetings, workshops, conversations, and saved chat logs. Slowly ufolding from this scattering of pads and notes we started to makes sense of what these infrastructures, technical practices and their knowledges were to us and how we desired to shape them.
These notes overflowed from the working sessions we had with other feminist server collectives such as Systerserver, Varia, and CC, where they shared with In-grid their practices and politics around setting up and maintaining these types of network infrastructures. Several interested in-grid members did not have the capacity to attend these initial training moments, and so to keep them updated we began this project's infinite-scroll-like pages of notes, code blocks and annotations. These notes included references to documentation from other collaborating groups, and to "official" documentation provided by the makers of the softwares we used. We felt it necessary to record the practical steps of the process, alongside more affective notes and asides to eachother. This allowed us to be ourselves, and express moments of connection to and around documentation that could otherwise be isolated and dispassionate.
Over time it became apparent that our unweildly scattering of notes and Servpub's particular setup, needed it's own technical docs to make room for these technical practices to takes shape from the backgrounds, relations and politics around this infrastructure. We go on to share how through these critical access informed docs made room to question how their inherited formats for sharing technical knowledges were sedimented within configurations to dictate bodies, practices and matters into determinate infrastructures, roles and relations. By doubling these technical praxis of documentation with critical access praxis we made room to access the relations, figures and politics iherited from their configurations, and make-sense for ourselves of how these normalizing relations misfitt our devious collective bodies. In making room for frictious misfitting, feeling the pressure and inflexibilty of configurations as to imagine how we desire to be collectivley (dis)oriented otherwise.
Sedimented Norms
Technical documentation is a technical form that has been standardised and sedimented within "traditional" computing contexts like computer engineering and before that from electrical and mechanical engineering . In these contexts, the promise of technial documentation is to provide a legible[1] understanding of how something was built and from there be able to maintain it within specific regimes and to develop it further within specific imaginaries of the system it is embeded within. The professionalisation of this artefact however, also means that the docs become a compendium of standardised and streamlined process of building . A process which, more often than not does not always follow a linear path. These docs through their efficient use give selective points of access to knowledge and practices that give the reader/user information that enables them to use the product/tool. The selection here orients them to give just enough information to make the tool knowable and practiced in the way it was intended to be, but also encoded so that only the specific people can access them. With Aimi Hamraie's tracing of the figure of the Flexible User (2017) it can be understood as a shaping of users and experts through flexings of soft bodies towards determinate hard machines and systems.
Through this encoding, encrypting and isolation of specific practices and their knowledges is also the erasure of the affective and human presence from the work. By prioritising efficiency systems and the sedimented institutional norms, these docs do not document the ways they demand bodies, communities, their infrastructures, and their knowledges to bend to their sedimented axis of politics in practice.
With Miriyam Aouragh and Paula Chakravartty's Infrastructures of empire (2016), we can understood how these promises of technological freedoms through specific determinate infrastructures, can bring with them their background and often the dominant militiaristic protocols and politics they are produced through.
Similarly, documentation for computational tools are built to provide just enough information for a user[2] to be able to work with a product and fix it where needed without "costing" the production company in the form of time spent providing customer support. By design, docs do not usually reveal beyond a certain level of utility of a system. Open source platforms will make more parts visible but not annotated or documented. That would usually remain inaccessible to anyone who doesn't already know how to navigate technical files or code.
Servpub Docs In-Praxis
Docs:00 Contents - transclude semi-plain intro to talk about bring critical access praxis in.
As we developed Servpub, In-grid's practice of copious, if atomised note taking, moved towards a pastiche of standarised technical docs. In this process of docs in praxis we met many times and of course made many notes. We took part in the workshops prepared by Systerserver and ourselves towards the more public events of the ServPub project, and tried to document the processes and procedures needed to replicate it for ourselves as individual learners, as well as share with other In-grid members and eventually wider communities.
These docs detail how to setup the different sections of the platform (wiki4print.servpub.net) where we co-authored and designed this book. This somewhat menacing setup is a reflection of how we attempted to respond to the form/conventions of technical docs. [expand on the progression of going from internal docs, to collectively hosted docs with Systerserver, to hosting them on w4p to then to including them as a reference to this chapter].
Expand: Articulate our response to that. How can we offer a response, why? What is the percieved gap we are trying to fill with these proposed docs?
But the process of creating something as seemingly neutral as techincal documentation, became more politically implicated as work, efficiency, transparent methods, etc became entangled in the choices we made. The docs that we eventually arrived at are somewhere between internal notes, technical docs and DIY instructions; a simply-written, narrative-moderate, set of instructions on building a self-hosted server with a VPN, set up for collective management/sysadministration.
The servpub docs themselves exist in several forms, one on the Gitlab hosted by Systerserver, one on in-grid internal, shared Github and one on wiki4print under the Docs category. From a practical perspective, this is a nebulous and difficult setup, making sure they are all up to date it has been a challenge . . . and indeed they are not in sync. There are also pre-existing separate docs for the Tinc setup by Xpub, Run Your Own and the many versions and docs of Wiki4print hosted on their wikimedia instances. This diversity of docs is someways an amazing thing as we can feel the backgrounds of these different groups come through, what do they care about? How are they practicing these technologies and infrastructures together? and how do they contextually share and make knowable the abstract constructed relations that make up these social technical practises? In other ways this can make these knowledges very inaccessible to different groups and communities. This can of course be done on purspose so that their has to be a certain level of intimacy given to the infrastructure, its politics, practices and technologies to manifest them. Here though In-grid in praxis with technical docs wanted to form a practises of knowledge sharing that could both orient towards being legible and accessible, but also towards holding our collective background that ServPub has emerged from.
Docs:03 VPN with Tinc refs of background knowledges etc.
Activating the docs
Talking about Apache logo for tinc + working sessions finding frictions/misfitting in praxis
Throughout this practice of technical docs we have been questioning how we can enable them to not only work across abilities and knowledges but also open up the technical practices they document to be interpretable and localised. In this section, In-grid reflects deeper on how we have inquired into this later step, enabling the docs and the practices they describe to be re-interpretable and re(con)figure-able by non-experts. To do this, we formed a set of workshopsfrom these docs that brought people together to do some basic sysadmin together, but along the way make space to highlight and take time to question the normalised and sedimented figures and relations of these infrastructures. We developed this workshop method as a way to not only make accessible the often obfuscated and encrypted practices of digital infrastructure, but to also bring them into dialogue with the operational concepts and metaphors they operate through. [Needs clarification: In doing this, we aimed to make a space where people can bring their embodied knowledges people have gained from doing these things, with the situated knowledges they brought with them. ] For us this was a space for us to think how we can bring in the methods of Amoore's (ref) cloud ethics as well as TITiPI's disobedient action research to open up and collectively dispute what these systems are, how they feel, and what we would want to imagine and metaphor them as.
We ran these workshops in two sessions, one at a combined panel at 4S/EASST in Amsterdamnand the other internally starting to set up In-grid's own digital infrastructures. The workshop at 4S/Easstwas run alongside a panel we ran exploring collective infrastructures, where we presented alongside TITiPI, NEoN digital, Júlia Nueno, as well as members of SHAPE who are involved in this project. The panel presented a spectrum of community organised infrastructure, and this workshop alongside meant to make accessible to the public In-grid's practices of collective re(con)figuring. The second workshop was run internally for In-grid members who were not specifically involved within Servpub and may have missed out on learning these skills or understanding these practices and their knowledges. This second workshop within In-grid also importantly moved from being an accessible representational process like we did at 4S/EASST to instead set up a VPS and foundational digital infrastructure for In-grid. In setting up this foundational infrastructure through this re(con)figuring practice, we aimed to have set it up with our own collective intentions.
Images of workshopping - more on the details of the workshopping could be good - understanding what is legible and whats not, particularly working with the docs to distribute where expertise are and to challenge normalised/violent metaphors or lexicons. Balanced against the need for the docs to be usable. [expand on this]
Talking about Docs:01.3 SSH and how we found friction with handshakes. (maybe quote from workshop pad as well . . .
Leaving Entangled
In-grid, and more largely the group involved with servpub as a whole, is made up of many individuals with still more multiple practices/praxises. It is shaped by our approaches and attitudes towards collective work, accreditation, labour and funding. These attitudes have have had material influence on the configuration of the tools and platforms we have used, and the form of sites like wiki4print. As we have worked to build an infrastructure which tries to reflect the desires and concerns of those who have built and will use it, we have also created a way of recording that work which include elements of our personhood. Traditional documentation ommits affective detail intentionally. On a practical level this is a useful way of keeping work succint, searchable and quick to parse and implement (ideally, anyway). What this can do however, is exclude none experts by glossing over information about why you might take a particular action in lieu of another, making steps appear arbitrary or opaque. If we are not able to understand the reasoning behind why a step has been taken in a set of documentation, it makes it difficult to deviate from that precribed path. If we are understand a process enough to make a decision about whether we want to follow that path or not, we are able to make more creative choices and cobble together different methods and approaches. Ommitting the personal and affective also obscures the experiences and perspectives of the people who made the work, and the situatedness of that work. The docs which exist on wiki4print are an intentioned to remain unmaintained at the time of publishing it more widely, as a record of the place and position we were at when the platform was made. A version will be hosted in a way where others can contribute to maintaining it, but the choice to create a static version both acts as a form of record keeping, but also reflects the fact that they were written by a group of precarious and fractional workers who can't commit to keeping them up to date indefinately. All this, being said, our leaving in of these more personal notes and asides do make the the docs more vulnerable, and more deeply entangled with our own partialities and politics. However, we welcome this complication, as we are happy to leave our practice entangled with our theory, and our code knotted in our conduct.
Foot notes
- ↑ Legibility can be contested when we talk about language written for and by a "specialist" group.
- ↑ this is a very non-human, commercialised role that is used to refer to an asbtract consumer of a tool as a product. It does not take into the account the reality, nuance, needs or real people with a desire or need to use / make-use-of-soemthing.
References
Acton, Kelsie. 2023. ‘Plain Language for Disability Culture’. In Crip Authorship, edited by Mara Mills and Rebecca Sanchez. New York University Press. https://doi.org/10.18574/nyu/9781479819386.003.0008.
Aouragh, Miriyam, and Paula Chakravartty. 2016. ‘Infrastructures of Empire: Towards a Critical Geopolitics of Media and Information Studies’. Media, Culture & Society 38 (4): 4. https://doi.org/10.1177/0163443716643007.
Hamraie, Aimi. 2017. ‘Flexible Users: From the Average Body to a Range of Users’. In Building Access. Universal Design and the Politics of Disability. University of Minnesota Press. https://doi.org/10.5749/j.ctt1pwt79d.6.
Pad up to date: https://pad.riseup.net/p/PraxisDoublingChapterNotes-keep