• kamo he/hum IT
• background
• development of custom software
• to facilitate
• agency-on
• comprehension-of
• complex systems
• before XPUB
• tools were never the main focus
• just instruments to be activated
• within particular contexts
• tailored to specific moments
• then forgotten

• During first year at XPUB something changed
• Working together with my classmates
• let me realize the importance of
• sharing tools
• develop not just for myself
• but also for others
• together with others
• code as common
• importance to create a space
• for these tools to circulate
• importance to build narrations
• around these instruments

• Prototyping writing machines
• to keep track of what's happening around us
• CMS
• wiki based
• git based
• jupiter notebook based
• Cookbooks
• soups
• reading methods
• Notation systems
• to annotate images
• to annotate synth
• Web-to-print
• click to print 80 000 post-it
• libretto for emergent opera
• this and other lists
• collecting things
• connecting things

• Every machine implies a different way to think
• requires to balance between different priorities
• accessibility
• susteinability
• flexibility

• Software development
• as a form of publishing
• as a form of care
• how to
• weave together multiple voices
• open to diverse knowledges
• share pov around software
• ?????? ? ?? ????

• Started thinking about documentation
• interesting surface
• interface between
• code
• user
• developer
• world
• not just as technical writing
• but also worldbuilding
• to orientate code in the world
• everything is a file
• everything is a frog

• README.md driven hackpacts
• Readme Driven Development, Tom Preston-Werner
• Documentation for the Padliography (with frogs)
• Documentation for the Workbook (with Supi)
• funny cover images 1 2 3
• writing docs together (with Chae) 4
• now i get triggered whenever doc is mentioned
• realized that writing doc is HARD
• and a couple of other things

• contradiction
• frustration while dealing with undocumented software
• and at the same time never documenting anything
• xquisite branch on git

• participation
• lack of documentation
• is a barrier
• for the participation of diverse knowledges
• in the the making of software
• At the same time
• this very lack
• could be a starting point
• A space to reclaim given margins and entry points
• A chance to overwrite what is normalized
• Let more voices participate
• in the discourse that is software
• examples
• RTFM, Mara Karaya‌nni
• Post-Meritocracy Manifesto, Coraline Ada Ehmke

• Chae drawings to explain API

• Supi design to diygest Flask

• worlding
• a way to produce narrations around software
• create a world for the code to inhabit
• to give affordances
• stretch what is possible
• to do or to think with it
• The Screenless Office, Brendan Howel

• recap
• community tinkering with code
• lot of experiments
• scattered all around
• not very public
• a generous group
• willing to share
• knowledge & software
• documentation seems an ideal surface
• to host ideas in close contact with code
• letting them entangle and shape each other

• elevator pitch starts after 12 min of intro
• what do you want to make?
• a small documentation framework
• focused on the development of situated software
• in the context of our group in XPUB

• situated software
• requires
• situated documentation

• So is this just a documentation of the Soupboat?
• yes
• no
• it's two things
• it starts as documentation around the Soupboat
• to develop a documentation framework for situated software
• chicken-egg meme

• docs
• a soft index of our software
• what do they do
• where to find them
• how to use them
• from where they come from
• and where are they going
• how we are documenting them
• how to contribute
• why are they important for us

• this docs is for two kinds audience
• internal public
• that would be us
• offer a way to keep track
• orientate knowledge
• share a common interface
• external public
• a way to navigate the Soupboat
• a rich ecosystem

• framework
• could a standard documentation framework work for us?
• not sure!
• our software are situated in specific contexts
• and contexts are different one from another
• there is not a single simple smart solution™
• no one size fits all
• what is there though are some common features
• small scale and tempo
• a sociality around software
• an economy of different knowledges
• so the plan is research through these aspect
• and curate a list of resources
• a framework
• to navigate this network of networks
• with the process of documentation

• a system of software & practices
• a list of
• references
• tools
• devices
• thoughts
• excercises
• hints
• fieldwork
• to articulate software documentation as a form of care
• without claim to catch everything

• shared surface
• one sentence games ritual
• the breakfast club
• flexible and expressive enough
• to be useful for us
• and accessible for others

• and this is maybe the moment for a small demo???
• flat markup bonfire

• related things
• url SI16 API
• A set of functions to mess around with vernacular language processing
• A collective work where everyone contributed with some functions
• Written in Python through Jupiter Notebook
• And documented in the very same notebooks
• With description, examples and references about input and output
• And then aggregated together as endpoints for the API
• example Shout function
• A choral API
• with multiplayer approach to documentation
• More docs for the backend is available
• url si16-backend

• the plan

• first 3 months passed experimenting with documentation

• the next 3 months are focused on
• internal public
• here i see myself as facilitator
• introducing the framework
• january is for offering them to the group
• adjusting it together
• februray is for prototyping software & practice
• march is for using the framework to curate an index of the Soupboat

• the last three months are dedicated to
• external public
• here i see myself as curator and designer
• to make our doc accessible from the outside
• our group will be busy with the projects
• writing contents for the documentation
• with the aid of the doc framework

• and then?
• after xpub?
• well i can see myself joining a new community!
• would it be another study program, a coop, a studio
• bringing the methods developed with this framework
• and adjust
• according to the new situation

• references
• Situated Software, Clay Shirky
• Post-meritocracy Manifesto, Coraline Ada Ehmke
• Situated Knowledges, Donna Harawai
• List and complexity: Annemarie Mol & John Law
• Diataxis Documentation Framework, Daniele Procida
• Readme Driven Development, Tom Preston-Werner
• Software Studies Revisited, W H K Chun, W Soon, N Wardrip-Fruin, J Zhu