This section about organizing Co-Learning rests on the assumption that learning always happens in a context, whether this context is a structured "course" or a (potentially) less structured "learning space". For the moment we consider the following division:

• Organizing Co-learning Contexts

  • Courses ("linked to a timeline or syllabus")

  • Spaces ("not linked to a timeline or syllabus")

This section focuses on existing learning contexts and examines in detail how they have been "organized" by their . At a "meta-level" of development, we can talk about this parallel structure:

• Building Co-learning Platforms

  • Development trajectories (e.g."design, implement, test, repeat")

  • Platform features (e.g.forums, wikis, ownership models, etc.)

A given learning environment will have both time-like and space-like features as well as both designed-for and un-planned features. A given learning platform will encourage certain types of engagement and impose certain constraints. The question for both "teachers" and "system designers" -- as well as for learners -- should be: what features best support learning?

The answer will depend on the learning task and available resources.

For example, many people believe that the best way to learn a foreign language is through immersion. But not everyone who wants to learn, say, French, can afford to drop everything to go live in a French-speaking country. Thus, the space-like full immersion "treatment" is frequently sacrificed for course-like treatments (either via books, CDs, videos, or ongoing participation in semi-immersive discussion groups).

System designers are also faced with scarce resources: programmer time, software licensing concerns, availability of peer support, and so forth. While the ideal platform would (magically) come with solutions pre-built, a more realistic approach recognizes that problem solving always takes time and energy. The problem solving approach and associated "learning orientation" will also depend on the task and resources at hand. The following sections will develop this issue further through some specific case studies.

In our analysis of our experiences as course organizers at P2PU, we (Joe Corneli and Charlie Danoff) used the US Army's technique of After Action Review (AAR). To quote from our paper [2]:

As the name indicates, the AAR is used to review training exercises. It is important to note that while one person typically plays the role of evaluator in such a review [...] the review itself happens among peers, and examines the operations of the unit as a whole.

The four steps in an AAR are:

1. Review what was supposed to happen (training plans).

2. Establish what happened.

3. Determine what was right or wrong with what happened.

4. Determine how the task should be done differently the next time.

The stated purpose of the AAR is to "identify strengths and shortcomings in unit planning, preparation, and execution, and guide leaders to accept responsibility for shortcomings and produce a fix."

We combined the AAR with our paragogy principles --

1. Changing context as a decentered center.

2. Meta-learning as a font of knowledge.

3. Peers provide feedback that wouldn't be there otherwise.

4. Paragogy is distributed and nonlinear.

5. Realize the dream if you can, then wake up!

and went through steps 1-4 for each principle to look at how well it was implemented at P2PU. This process helped generate new policies that could be pursued further at P2PU or similar institutions. By presenting our paper at the Open Knowledge Conference (OKCon), we were able to meetP2PU's executive director, Philipp Schmidt, as well as other highly-involved P2PU participants; our feedback may ultimately have contributed to shaping the development trajectory for P2PU.

In addition, we developed a strong prototype for constructive engagement with peer learning that we and others could deploy again. In other words, variants on the AAR and the paragogical principles could be incorporated into future learning contexts as platform features [3] or re-used in a design/administration/moderation approach [4]. For example, we also used the AAR to help structure our writing and subsequent work on paragogy.net.

We surveyed members of the Peeragogy community with questions similar to those used by Boud and Lee [1] and then identified strengths and shortcomings, as we did with the AAR above.

These were discussed, refined, and answered on an etherpad: revisions to the original set of questions, made by contributors, are marked in italics.

1. Who have you learned with or from in the Peeragogy project? What are you doing to contribute to your peers' learning?

2. How have you been learning during the project?

3. Who are your peers in this community, and why?

4. What were your expectations of participation in this project? /And, specifically, what did you (or do you) hope to learn through participation in this project?/

5. What actually happened during your participation in this project (so far)? /Have you been making progress on your learning goals (if any; see previous question) -- or learned anything unexpected, but interesting?/

6. What is right or wrong with what happened (Alternatively: how would you assess the project to date?)

7. How might the task be done differently next time? (What's "missing" here that would create a "next time", "sequel", or "continuation"?)

8. How would you like to use the Peeragogy handbook?

9. Finally, how might we change the questions, above, if we wanted to apply them in your peeragogical context?

Lisewski and Joyce: In recent years, the tools, knowledge base and discourse of the learning technology profession has been bolstered by the appearance of conceptual paradigms such as the 'five stage e-moderating model' and the new mantra of 'communities of practice'. This paper will argue that, although these frameworks are useful in informing and guiding learning technology practice, there are inherent dangers in them becoming too dominant a discourse. [5]

Instead of a grand narrative, Peeragogy is a growing collection of case studies and descriptive patterns. As we share our experiences and make needed adaptations, our techniques for doing peer learning and peer production become more robust. Based on the experiences described above, here are a few things people may want to try out in future projects:

• "Icebreaking" techniques or a "buddy system"; continual refactoring into teams.

• Maintain a process diagram that can be used to "triage" new ideas and effort.

• Prefer the "good" to the "best", but make improvements at the platform level as needed.

• Gathering some information from everyone who joins, and, if possible, everyone who leaves.

1. Boud, D. and Lee, A. (2005). 'Peer learning' as pedagogic discourse for research education. Studies in Higher Education, 30(5):501--516.

2. Joseph Corneli and Charles Jeffrey Danoff, Paragogy, in Sebastian Hellmann, Philipp Frischmuth, Sören Auer, and Daniel Dietrich (eds.), Proceedings of the 6th Open Knowledge Conference, Berlin, Germany, June 30 & July 1, 2011,

3. Joseph Corneli and Alexander Mikroyannidis (2011). Personalised and Peer-Supported Learning: The Peer-to-Peer Learning Environment (P2PLE), Digital Education Review, 20.

4. Joseph Corneli, Paragogical Praxis, E-Learning and Digital Media (ISSN 2042-7530), Volume 9, Number 3, 2012

5. Lisewski, B., and P. Joyce (2003). Examining the Five Stage e-Moderating Model: Designed and Emergent Practice in the Learning Technology Profession, Association for Learning Technology Journal, 11, 55-66.

• Heartbeat

• Roadmap