Peeragogy.org

☰

Organizing Co-Learning

« Back to Peeragogy.org

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 with 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, nearly everyone agrees 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.

Case Study 1: “Paragogy” and the After Action Review.

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:

  • Review what was supposed to happen (training plans).
  • Establish what happened.
  • Determine what was right or wrong with what happened.
  • 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:

  • Changing context as a decentered center.
  • Meta-learning as a font of knowledge.
  • Peers provide feedback that wouldn’t be there otherwise.
  • Paragogy is distributed and nonlinear.
  • 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 presenteding our paper at the Open Knowledge Conference (OKCon), we were able to meet P2PU’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.

Case Study 2: Peeragogy, Year One.

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

Questions

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

  • Who have you learned with or from in the Peeragogy project? What are you doing to contribute to your peers’ learning?
  • How have you been learning during the project?
  • Who are your peers in this community, and why?
  • 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?
  • 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?

  • What is right or wrong with what happened (Alternatively: how would you assess the project to date?)
  • How might the task be done differently next time? (What’s “missing” here that would create a “next time”, “sequel”, or “continuation”?)
  • How would you like to use the Peeragogy handbook?
  • Finally, how might we change the questions, above, if we wanted to apply them in your peeragogical context?

Reflections on participants’ answers

Some of the tensions highlighted in the answers are as follows:

  • Slow formation of “peer” relationships.There is a certain irony here: we are studying “peeragogy” and yet many respondents did not feel they were really getting to know one another “as peers”, at least not yet. Those who did have a “team” or who knew one another from previous experiences, felt more peer-like in those relationships. Several remarked that they learned less from other individual participants and more from “the collective” or “from everyone”. At the same time, some respondents had ambiguous feelings about naming individuals in the first question: “I felt like I was going to leave people out and that that means they would get a bad grade - ha!” One criterion for being a peer was to have built something together, so by this criterion, it stands to reason that we would only slowly become peers through this project.
  • “Co-learning”, “co-teaching”, “co-producing”?One respondent wrote: “I am learning about peeragogy, but I think I’m failing [to be] a good peeragogue. I remember that Howard [once] told us that the most important thing is that you should be responsible not only for your own learning but for your peers’ learning. […] So the question is, are we learning from others by ourselves or are we […] helping others to learn?” Another wrote: “To my surprise I realized I could contribute organizationally with reviews, etc. And that I could provide some content around PLNs and group process. Trying to be a catalyst to a sense of forward movement and esprit de corps.”
  • Weak structure at the outset, versus a more “flexible” approach.One respondent wrote: “I definitely think I do better when presented with a framework or scaffold to use for participation or content development. […] (But perhaps it is just that I’m used to the old way of doing things).” Yet, the same person wrote: “I am interested in [the] applicability [of pæragogy] to new models for entrepreneurship enabling less structured aggregation of participants in new undertakings, freed of the requirement or need for an entrepreneurial visionary/source/point person/proprietor.” There is a sense that some confusion, particularly at the beginning, may be typical for peeragogy. With hindsight, one proposed “solution” would be to “have had a small group of people as a cadre that had met and brainstormed before the first live session […] tasked [with] roles [and] on the same page”.
  • Technological concerns.There were quite a variety, perhaps mainly to do with the question: how might a (different) platform handle the tension between “conversations” and “content production”? For example, will Wordpress help us “bring in” new contributors, or would it be better to use an open wiki? Another respondent noted the utility for many readers of a take-away PDF version. The site (peeragogy.org) should be “[a] place for people to share, comment, mentor and co-learn together in an ongoing fashion.”
  • Sample size.Note that answers are still trickling in. How should we interpret the response rate? Perhaps what matters is that we are getting “enough” responses to make an analysis. One respondent proposed asking questions in a more ongoing fashion, e.g., asking people who are leaving: “What made you want to quit the project?”

Discussion

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.

References:

Previous: « P2P SOLE   Next: Adding structure »