How to document the Relearn tools without becoming tool-centric?
Focus on the effect of the tools? what learning processes are facilitated by the tools themselves?
- local network
- etherpad
- xmpp
- git
What tool do we use to document the Relearn tools?
Also on a meta level : what do we do with the distribution/accessibility/potential updates to the archive (so, new tools in the coming years).
xmpp
things that could be included:
- how-to-install tutorial
- contextualize why we decided to use xmpp in Relearn 2017
- The Homebrew Server Club is a group from Rotterdam which is meeting regularly to discuss self hosting options. Their last meet ups have been revolving around the XMPP protocol and the possibility to host your own chat server and exchange messages away from corporate eyes. As a result of their meetings, a guide was put together with an introduction on how to DIY. XMPP is very much in tune with the topic of this year's Relearn - co autonomies - because it allows a federated communication, where each user can decide where to store their messages, but still communicate with each other.
- Conscious decision to bring in a new tool in the Relearn toolkit
- Two possible functions: chat/sharing but also documentation reasons (eg archivist bot)
- what material it produces
- conversation logs: functional? poetic? educational?
- overview of physical environment (mentions of what people were up to outside of the pad)
-
- feedback & impressions, did it work as a communication tool for Relearn?
- time did tell
- some people were reluctant to make yet another account on a chatting app, but got very excited about the possibility to make bots towards the end of the week
- it seems like the bots worked better as a way to think through the archive than as a method of communication
- how-to-make-bots tutorial
- not particularly developed, but it's there!
- pictures & screenshots
tools that we could use to document:
- git - For the building process git would be useful. To see the progression of building this archive. But, there is not much time to create this documentation, which would turn into big commits. Therefore, versioning this process feels a bit silly.
- etherpad - Good for collective work & thinking. Is already archived by the Etherdump tool.
- plain text file (README file?) - difficult to work on the file collaborately. However, we can turn the etherpad (this etherpad) in a plain text file in the end. But: why not html then? Or pdf?
Will this tool documentation be an archive?
Will this tool documentation be part of the documentation of Relearn?
*Miglena's physical git workshop
PADS
http://complex.local/etherdump/xmpp_carousel.diff.html
http://complex.local/etherdump/local_network_carousel.diff.html
http://complex.local/etherdump/local_network.diff.html
http://192.168.73.188:9001/p/tool_carousel
http://complex.local/etherdump/complex.local.diff.html
LINKS
https://github.com/ether/etherpad-lite/wiki/How-to-deploy-Etherpad-Lite-as-a-service
http://www.reganmian.net/blog/2014/10/03/supporting-idea-convergence-through-pedagogical-scripts/
https://pypi.python.org/pypi/etherpad_lite/
https://github.com/graphiclunarkid/etherpad-saver
https://gitlab.constantvzw.org/aa/etherdump/tree/master/etherdump/commands
our ETHERPAD API key
ced8c0068ef893d1a47f900560226a65e16ef4f1905f777399ea86c870930e03
python -m etherpad_lite -p apikey=ced8c0068ef893d1a47f900560226a65e16ef4f1905f777399ea86c870930e03
A simple helper function to execute Etherpad API calls, and properly format the return message:
def run_etherpad(path, **params):
params['apikey'] = settings.ETHERPAD_API
data = urlencode(dict(params)).encode('ascii')
url = ("%s/api/1.2.10/%s" % (settings.ETHERPAD_URL, path))
r = json.loads(urlopen(url, data).read().decode('utf-8'))
return(r)
http://etherpad.org/doc/v1.3.0/#index_api_methods
createPad padID=testingstuff text="Lorem ipsum dolor sit amet."