You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

10 KiB

trolley de la muerte

  • 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


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

goat and cheese

  • 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

pad as frogs

  • 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 Karayanni
  • Post-Meritocracy Manifesto, Coraline Ada Ehmke

chae api drawing

  • Chae drawings to explain API

supi flask design

  • 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


  • 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