...
 
Commits (2)
......@@ -6,62 +6,44 @@ maintainers: Jared Pereira (jared(at)awarm.space)
## Abstract
A Learning adventure is a standardized format for experimenting with novel
learning structures for individuals and groups. Each adventure consists of three
parts: a map, artifacts, and a reflection.
The Learning Adventure offers a standardized format for people to engage in formal learning outside of an institutional context.
The goal of the learning adventure format is to create a scoped, structured
space, for people to engage with formal learning _outside_ of an institutional
context. By capturing experiences and intents in a standardized format we allow
others to learn from and build on past experiences.
The goal is to capture a learner's intents, processes and reflections in a way that can be documented and shared. This allows others to benefit from past Adventures, and build upon them. Learning begets more learning!
Learning Adventures are also a kind of staging area for [FNS
structures](../), a way to experiment with them and get real world use
before they are formalized into the canon.
Each Adventure consists of three parts: a Map, a Log, and Artifacts.
## Examples
- [FNS Learning Adventures](https://gitlab.com/_fns/adventures)
## The Process
Each learning adventure lasts for a fixed period of time, at most 6 weeks.
### 1. The Map
The first step of a learning adventure is defining the map. This is the document
that sets out the plan for the adventure, what's being learned, what structures
will be used to learn it, and who'll be involved.
The first step of an Adventure is creating the Map, a document that lays out the learning plan. It should include the following:
- content: _what_ the learner will be tackling
- questions: seeking these answers will drive the inquiry
- process: _how_ the learner will go about the Adventure
- participants: _who_ will be involved
- period: proposed start and end dates for running the Adventure
Importantly the map must include questions that will be answered after the
learning adventure has been completed.
The Map should also link to three things that will be key to carrying out the Adventure: the Location, the Log, and Artifacts.
### 2. Running the adventure
Each adventure should have a reference to where it's being run, whether that's
on [are.na](https://are.na), in a [gitlab](http://gitlab.com) repository, or through a
[youtube](https://youtube.com) channel.
##### The Location
The map should designate an online location where the Adventure is being run.
This could be a personal website, a community platform like [are.na](https://are.na), a code repository such as [gitlab](https://gitlab.com/), or even a place like a [youtube](https://youtube.com) channel.
### 3. Collecting Artifacts
An adventure will likely produce some outputs, whether a log of what works been
done, source code, or art produced. These should be collected and published
along with the adventure map.
### 2. The Log
The Log is the learner's account of their Adventure. Whereas the Map lays out the plan in advance, the Log describes how the Adventure actually unfolds. It could be kept as a journal or blog, even embedded in the Location selected for the Adventure. It needn't be super formal or lengthy, but it should try to capture key moments on the journey. Finally, the Log should end with a reflection on the Adventure: how it went, which practices were and weren't effective, and thoughts on how it could be improved upon. The Log should be linked to from the Map.
### 3. Artifacts
A learning Adventure should produce some Artifacts, or outputs, along the way. They could take any of a number of forms, such as source code, photos, drawings, or video. They might even consist of writings that are incorporated into the Log. As outputs of the learning process, artifacts needn't be pretty or polished. They can be reflective of an interim state. However, it's helpful if they are given some context. They should be assembled as files or links, and published along with the Map and Log.
### 4. Reflecting
Finally it's important to reflect on how the structure of the adventure worked,
what was and wasn't effective.
## Collecting Adventures
While you can use this process entirely for yourself it may be useful to collect
adventures into a larger social context to help keep you accountable, and to
share the results.
Hosting Adventures in a community repository helps boost their accountability for the adventurer. It also enables greater sharing of learning.
A community repository should enforce certain standards around Adventures (e.g., that they should be well defined, scoped to a particular field, ensure that the learner has serious intent to follow through, etc.). The easiest way to do this is to have assigned "Editors" who vet every learning adventure.
An adventure repository should enforce a standards around adventures (i.e that
they're well defined, that individuals seriously intend to undertake them, that
they're in a particular field). The easiest way to do this is to have assigned
"Editors" who vet every learning adventure.
## Goal
## Motivations
The goal in creating the Adventures process is to make experiments in self-directed learning achievable and accessible.
The goal of the Learning Adventure process is to make experiments with learning
structures achievable and accessible.
......@@ -28,7 +28,7 @@ and use.
- [FNS Structures](#fns-structures)
- [Motivation](#motivation)
- [How do we create new structures?](#how-do-we-create-new-structures)
- [How can you create a new structure?](#how-can-you-create-a-new-structure)
- [Step 1. Propose a new structure](#step-1-propose-a-new-structure)
- [Step 2. Test the structure and gather some examples](#step-2-test-the-structure-and-gather-some-examples)
- [Step 3. Format the structure for submission](#step-3-format-the-structure-for-submission)
......@@ -40,17 +40,15 @@ and use.
<!-- markdown-toc end -->
# How do we create new structures?
# How can you create a new structure?
Do you have an idea for a learning structure that you'd like to propose? Anyone is welcome to contribute!
Just follow the steps below:
## Step 1. Propose a new structure
If you have an idea for a new structure to help with learning, start by opening
a ~Proposal issue. In it you should describe the structure, how it helps with learning,
and how it can be implemented in actual practice. While not mandatory, it's also
recommended that the structure you're proposing is something that: you've actually
Start by opening a ~Proposal issue. In it you should describe the structure, how it helps with learning,
and how it can be implemented in actual practice. While not mandatory, it's recommended that the structure you're proposing is something that: you've actually
used, you're planning to use, or you've observed firsthand (See Step 2)
## Step 2. Test the structure and gather some examples
......