online pad for this track:

From library studies working on archiving the work of an artist. From there looking at 'non-developer' uses of git as a versioning system. 

Some angles / questions:
        in what ways could Github be useful as an archive?
        how does the network get activitated and stay active within Github?
        what roles do concepts such as provenance, appraisal and selection have in Github?
        how to capture the context of the network?
        what are ways to repurpose Github for archivists / non-coders?
        how to extend the 'life of documents' by means of forking?

This track will acquint participants with git and github, by working together on repurposing Github's functionality and experimenting with how version control can be integrated in the practice of creating an archive. At the same time, exploring the post-life of github repositories through forking, as a method of building on the work of others and creating new archives.
Alongside the practical experimentation, and in order to gain a better understanding of the underlying, but omnipresent, structures that support these archives and projects, we will also discuss the value of these networked archives / projects. If networked archives/projects are influenced by material conditions and take place through relations and being part of socially organised systems, then how do different elements and entities influence each other, its aesthetic and development? How are these networks articulated and how do they evolve? What are the different stages of (aesthetic, social and technological) development? What is the impact of changes from inside and outside influences, whether networks are dependent on specific structures or formations, or what kind of systems support or obstruct the evolution of networks? How open are they and when do they transform into something else? In what ways will variable or versioned networked archives affect the authority of the institutional organisation? How will their power in the era of openness, self-referential systems and active users change in favour of (co-)developing strategies that bridge varieties of cultural actors and professionals?

 To answer some of the question we will also discuss some existing examples/text/research, for example [perhaps prep. reading]:
- Fuller et al.  "Big Diff, Granularity, Incoherence, and Production." In Memory in Motion: Archives, Technology, and the Social, edited by Ina Blom et al. - free download
- Hui, Yuk and Harry Halpin. 2013. Collective Individuation: The Future of the Social Web. In Unlike Us Reader. Social Media Monopolies and Their Alternatives. INC Reader 8, edited by Geert Lovink and Miriam Rasch. Amsterdam: Institute of Network Cultures, pp. 103-16.
- Lovink, Geert and Ned Rossiter. 2005. Dawn of the Organised Network. The Fibreculture Journal. Vol. 5, No. 29. Website
- Tufekci, Zeynep. Twitter and Tear Gas. The Power and Fragility of Networked Protest. New Haven/London: Yale University Press, 2017. Chapter: The Networked Public - free download
- Mansoux, Aymeric, "Fork the System", chapter 8.2 in Mansoux, Sandbox Culture, 2017, PhD dissertation. PDF:
- Snelting, Femke, "Distribtued Version Control." in: Conversations: pp. 109-29.
- Ofer Bergman and Steve Whittaker, The science of managing out digital stuff

Some practical examples / initiatives : /
The Syrian Archive
Community architecture (RedHat)
Self-archiving, open access repository for art publications

Version control in the arts and in arts' conservation:
Raphael Bastide 1962 project >> influenced by Robert Morris' Location (1962)
Do it manual
Raphael Lozanno-Hammer
Brandon (web work restoration) [from 15:20] >> /

Github for designers? <- presented at LGM2016, in a presentation that fethisized the 'genius' of the artist.


Non-code based github projects:
Marriage proposal of GitHub
Why GitHub cannot host the Linux kernel communituy

On github centralization / monopoly:
Le danger Github (revu et augmenté) :
The Problem With Putting All the World's Code in GitHub:
GitHub is too centralized:
GitHub was down:

aaaaaaaaaaaan slideshow

Program outline [under construction]

DAY 1:
Into: What are are going to be looking at in this track?

DAY 2:
10:30 - 13:00 morning session
- Version control through git: Git Physical (workshop): Git-physical
-- Part 1: workshop (no computers needed)
-- Part 2: CLI exercise
--- Markdown syntax
--- Browser markdown editor
--- Vim documentation
- Toolbox: Skills and technology (overview)

14:00 - 18:00 afternoon session
Introduction into archival practices: Institutional vs grass roots 
- Slides Annet:
Human capital: Communities and networks (discussion)
Materials from the Poortgebouw Archive: What we can experiment with? (ideation)

DAY 3: 
10:30 - 13:00 morning session
Archive's aim: Definition, audience/users, and evolution (discussion)
Planning and execution: further experimenting with tools

14:00 - 18:00 afternoon session
Networks: from theory to practice and practice to theory
- how to create sustainability
- reflection on existing models/guides (for example, Red Hat / Mozilla / Internet Archive / Wiki-media-pedia-data / ANT / Hui&Halpin)
Metadata and categorisation vs folksonomies, or/and search engines (visual versus text)

DAY 4:
Self-directed work t.b.d. depending on the process and progress of the previous day

DAY 5:
Presentations: what do we (not) have and why is that important

a link to the Poortgebouw Archive project:
Note: the Poortgebouw archive project is part of the exhibition (the exhibition ended)


Notes from the track introductions

The track was a merge of two tracks. 

One being around git & version control.
Git was never introduced in Miglena's design and library degree.
Raphael bastide, uses github for non-code-based work. He is documenting his sculptures through git.

Versioning control appeared for Miglena during her studies in document management systems.

Version control systems offer a combination of
- document records
- file system

Interest in the context of art and design

Annet's interests
How incredibly standardized the archive discourse is.
Coming from a media art background.

How can git and version control systems being used to archiving systems?
Versions are difficult to retrace in archive systems. 

Specifically worked in net-based art projects, there are a few examples to list.


There are also downsides on the element of version control systems, as there are things you don't want to keep.

Example of a versioning controlled net-art work:
Guggenheim museum is using versioning control to track changes that they make in the files and code. But, the code and neither the comments are published. The museum has only published an article about the proces. Did they use git only for themselves? To be able to go back if needed?

Github is used as a publishing platform in some cases, but then the versioning control side is not used at all. 
This is also the case for many font projects.
But even then github is useful, because you can fork the font.

The blockchain as a technique that re-fetishizes the original.

Depending on your intention, how do you use git in your practise?

What does versioning control mean for a designer?
What do you do with all the versions?
How do you select?
What is the moment you want to save or commit?

An example of OSP's Visual Culture, which is a tool that is made for the OSP website, coming from an aim to track visual versions.

Wednesday 30th of August

POORTGEBOUW discussion
legal purpose: local autonomous, using media wiki > annotate around the document / how people interact with the documents. Problem/challenge people, documents and relation between them, and technical aspects.
documents don’t change but meta data might change and the context.
Legal aspects and cultural relevance.
What’s done / workflow: selection documents, OCR, title, date, author, upload, create page in wiki, people in community comment/add.
Categories: many talks, no coherent plan, also documents incoherent – sof or now it is restricted to years + keywords/labels. 
Like to create different ways of relations, explore semantic challenges + make visualisation and timeline. Disadvantage that media wiki uses a lot of plug ins that aren’t always maintained.
archive based on media wiki, also tried semantic wiki and active archive system by constant

other examples: library stack
IISG, Amsterdam might be interesting to parallel archiving
May Day Rooms, London

git hub restriction 100 mb

how to make version control more user-friendly, if assuming that it might become a commonality in few years?
what are the needs: historical, curatorial etc > flexibility in mode of access

differences media wiki - git
media wiki whan it's working it's useful and accessible to work with, but when it falls over becomes more difficult to retrace files, might be the other way around with git (as it is just files).
media wiki not just a protocol also interface, git is essentially a protocol not an interface
git is made for tree hierarchies, media wiki more about categories / groups which are more horizontal to each other

Autonomous (Poortgebouw) Archive

Relearn archive

different version control systems of the etherpads on complex.local

Etherdump version control excercise
The bare repository is located at /var/www/html/git/etherdump-version-control.git
To clone the git repository:

to upload a file to complex.local
$ scp filename.pdf complex.local: 
> this will upload it to your user's home 
$ scp filename.pdf complex.local:/var/www/html/
> this will upload it to the main folder that you see when you go to complex.local

Thursday 31 August
compare different systems: media wiki (autonomous archive/poortgebouw) / git lab (relearn) / git lab (documentation/conservation related) / etherpad
come up with arguments to use (not use) these systems as archival tools

questions / versioning:
    what is the added value
    define the goals
    describe the (re)user
    functions / functionality; what doed it do/need to do/not do
    how to appraise/select
    integrate metadata/commit

(a start)
A public archive of/for Relearn.
For the new group of Relearn next year.
And for people that did not attend Relearn before.

What is it that we want to save?
The content? The questions that were asked? The structured?
If we focus on the structure, the content is left open to be filled in, in a next year. - The etherdump gitlab repository from Michael

Two things that need to be done before publishing the etherdump

Preparing etherpads during the week for archiving them into different file types
The tool etherdump parses the text on the etherpads as markdown. Markdown syntaxt such as headers (#header will make a <h1></h1> element) are useful, as they can then be transformed into html/pdf/other documents. (well... not in this version on our server...)

gitlab is not really a reading interface
gitlab is called a collection management system/software
gitlab is therefore not really an archive

"archive": read, no write, fixed > have a specific function to show the events/actions of a person/business/organisation and they are specifically selected for long time preservation / these are unique objects (difference with fe libraries that house copies etc)
archives cover the records themselves as well as their context of creation, management, use and the socialcultural context.
"record keeping": businesses, changing, in process - making and managing records / systems by which and how records are created and maintained, including the peopel that are part of this process (also the term records management is used)

collection: less committed to regulations


file structure of 2016
omnius.calafou (the selection of the Relearn archive that has been prepared as a gift for the Calafou community)

+ gallery of images at Constant's server

But then, what about the stucture of Relearn outside the server?
Perhaps we need to be more precise with our aims. If this archive is here to support future editions of relearn, some additional edition has to be added (funding process > duties etc).

why an archive???

Relearn as an event that exist in between the Relearners.
How can we let the archive exist in between people too? And not place it at one location.
a distributed/federated archive?
an archive that evolves and has similar properties that reflect the actual 'working' days

Gitlab: an usb-stick that is available for everyone.
Create torrent file & distribute !

media wiki pros
goal publishing tool

media wiki cons

Gitlab pros

Gitlab cons
goal: software/code development triggered by linux 

version control is useful for archives at the point of creation, but less so in hindsight when trying to 'file' or 'archive' existing content

‎"notetaking is not sharing is not documenting is not archiving is not publishing" (Relearn 2015, )

Relearn archive? Relearn tools?
Instead of working on a central Relearn archive, focus on the tools that has been developed over the years? Maintain them, improve them, and create new ones. As a way to make it possible to continue working in this type of setup? 
For example: tools like etherdump & local network setups are also being used in various Constant events. And the etherpad has become a tool at the Piet Zwart Institute.
Is it about preserving the means?
Would it be possible to create a Relearn without the tools we have been using and also use at the moment? (etherpad + etherdump + xmpp + git (for publishing) + local network)

the tools are essential only because they embed convivial values that are (at) the root (user) of relearn. xmpp is a new addition. has it worked until now? the many iterations of relearn are subject to their hosting environment. the rotterdam edition brought a tool which has been used by another rotterdam-based group: homebrew server club

- finding a way to document what the tools enabled for the participants, which needs they were here to cover and so on... so for the future relearn, organisers can adopt or rethink the whole structure of collaboration within the event?

for an archive one adds a layer for later, with version ontrol you create a community/network or social layer of communnication at the moment of creation. for example etherpad has a very different time dimension
Etherpad has a maximum delay of 500ms (=0.5sec)
some thoughts:

 versioning: construction of time and common state
- etherpad: to construct a common state in real-time during collaborative process (max 500ms delay)
- mediawiki: common text, but with archive of which author made which changes -> author trail
- git: create common state of code, with archive of versions and authors -> archives (code) development process
Both mediawiki and git use longer delays but are useful for different sort of end product (text vs code)
Conclusion: versioning makes not a lot of sense for archiving, except when you want to archive the development process itself. 

The versioning has to happen within the actual process, not outside of it. That means the versioning has the function to create a common state within that process, archiving of the process is a side effect. 
When using versioning outside of the process, it is a storage of different objects. In that case other tools and processes are probably better suited. Creating a common state through versioning is a very specific form of ensuring the authenticity and integrity and creating accessibility compared to an archive.

- construction of narratives -> important question is which narratives need to be constructed out of it 
- construction of memory -> memory as narrative or as building stones for narratives

An archive as the creation of a semantic network of objects/texts through which specific narratives can be constructed.
The archiving process takes place later than the actual archived objects/texts and establishes a specific narrative or semantic layer. In code development the semantics is about the common state of the software established during that process.

tools solidify the interaction between users
necessary to document the reasons for choosing them?

Relearn2017 archive discussion is versioning previous Relearn archive discussions : we're RUMINATING :-)
reroam > rerumen 

It would be nice to make a reader with the reroam materials, to be able to read it :) yes! illich is a returning tag element

is relearn a one-week only event? if not, how do the discussion points travel and manifest and take another shape/iteration in one year's time?
^ 'looking through the repository' was a way to reactivate the material that had been collected throughout the week

How to document the Relearn tools?
Focus on the effect of the tools? what learning processes are facilitated by the tools themselves?

We continued here:

GITLAB exercise for preservation / documentation purposes:

and wiki in process

etherpad export:
    - .html -> with html formating tags but no authors tags
    - .etherpad -> all versions

etherpad import:
    - .etherpad -> need a fresh pad without changes
    - .txt -> remove previous changes -> hand crafted visual interface for Git, displaying commit messages and the files. Unfortunately tracking the changes between the image files remains a "pending project"