Open source processes rely on solid documentation to allow people who were not associated with the creation of something to replicate these result in their own contexts. In software we see this through the GitHub repository. In cosmo-localization there are communities, like FarmHack, that emphasise the importance of documenting the development process.
Similarly, with social innovation, which is what FuturesLab is all about, documentation is key, allowing others to understand the processes we took and the way experiments were conducted. This allows people to learn from this and adapt and modify this. One of the core ideas in FuturesLab is simply that, keen though the process may have stopped for us – e.g. we decided not to pursue an idea, another person may decide to start off where you left off. A bit like a baton race, where you may have done the first lap, but then others will do subsequent laps.
But documentation can be confusing and also time-consuming, The key is to include the minimum amount of information needed for someone else to “take the baton” and start off where you left off, but no less than this minimum. Too little information and people cannot really “reach the baton”, but too much info can be onerous to document and it may prove overwhelming to people wanting to engage with the idea. This is similar to Einstein’s notion that “Everything should be made as simple as possible, but no simpler.”
So what is this scaffold? Here are some guidelines:
- Provide a few sentences on the circumstances and context, where something happened, when it happened, and why it was done, etc.
- Provide a summary of what the process attempted to do. What was the intention of the event or process?
- Provide a distinct summary of the design or methodology, something that others would be able to follow and replicate.
- Provide a sentence or two on what happened – what was the experience like?
- Provide a summary of what was learned in the event or process. This can be boiled down to 3 main points for brevity and simplicity.
- Provide a sentence or two on what is next?
Overall this documentation can be as short as 200 words but should really be no longer than 700 words. It needs to be accessible and in plain language.
FuturesLab 