tag-list/README.md

# tag list

Would like to try a more file oriented approach for writing tagged list. Right now I'm thinking to have a folder full of more or less small files. Every file has a first row with tags, and then the contents.

for example

```
food, recipe
pumpkin soup is made with pumpkin and fire
```

Reserving the first line for the tag is simple and probably powerful enough to write without constraining structure.

Then i can imagine something like `grep`ping those files and providing ways to merge and order them via commandline.

Let's see

## categories.sh

Print a list of all the categories currently used in the txt files.

`./categories.sh`

output

`community complexity economy hackpact law list mol multiplicity ooc padliography project quote readme research soupboat susteinability versioning work workbook`

## category.sh

Print the contents of all the files that are tagged with a category

`./category.sh category`

example:

`./category.sh hackpact`

output

```
-   #01 Where does software documentation begin and where does it end?
-   What about README files, tutorials, guidelines, comments in the source code, and demos?
-   How porous or tentacular is this surface?
-   Set some references by looking back at the works made last year and read them through the axis of code and care.
-   Explore common templates of documentation and their habitability.

-   #02 Write documentation & focus on its contents and style
-   Write documentation for selected prototypes from the many made last year.
-   Could this process create a new public, or transform their original ones?
-   As initial case study focus on the [Padliography](https://hub.xpub.nl/soupboat/padliography/), a tool developed within XPUB to keep track of the amount of scattered Etherpad documents used to take notes and work togheter.
-   During last year it's been used only in the context of our class, but after some adjustments it's now flexible enough to be offered also to other constellations orbiting around the _XPUB & Lens-Based wiki_.

-   What does it mean to offer it to someone else?
-   How to talk the same language in different contexts?
-   How to be clear without oversimplifying?

-   #03 Write documentation & focus on the process of writing
-   Open the writing process and experiment collaborative practices for the documentation of the [Workbook](https://hub.xpub.nl/soupboat/workbook/)
-   A tool developed together with Supi to keep track and annotate configurations for different instruments and facilitate learning process.
-   Write the documentation together.
-   Could there be multiple voices or is necessary to keep a single point of view?
-   What does it mean to write with different intensities?
-   Can we imagine ways to zoom in and out details level?
-   How different knowledges can participate in the process?

-   #04 Write documentation & focus on the surrounding context

-   Expand the research to tap into ongoing projects outside XPUB, such as freelance work and parallel research
-   candidate could be : [Object Oriented Choreography](../ooc-summer-session/), a performative project of mine related to networked technologies, VR and contemporary dance.

-   Are there ways to make the documentation process more sustainable (socially, economically)?
-   Are there strategies to overcome low-resources environments?
-   Search for escamotages to create space and energies to document.
-   Use documentation to work with collaborators, clients, and end-users and approach code from multiple point of view.

-   Try to infiltrate the industry of software development through documentation.
-   Attempt to expose their public to these issues in subtle ways.
-   Offer entry points and escape routes from the automatic outcomes proposed by tech solutionism.
-   Offer alternatives to sedimented roles in the care of software.

-   #05 Write documentation & focus on who is writing it

-   What are the relations between documentation and the community around a software?
-   Experiment with versioning.
-   Try to have several instances of the same documentation.
-   Try to question who gets to write and who gets to read the documentation.
-   Shift the moment in which the documentation happens.
-   Where the documentation is hosted?

-   Question the nature of the documentation
-   what does it take for granted?
-   For what kind of public it is produced
-   what kind of public does it produce?
-   How does it normalize the context around the software?
-   What are its politics of access?
-   How does it create entry points and how does it gatekeep?

-   #06 #07 #08 Towards final project

-   Collect and organize the outcomes from the different hackpacts.
-   Trace trends and synthetize common and diverting aspects.
-   Research for a surface that could host this different facets.
-   How can it inhabit the usual places where documentation is hosted?
```