Main Data History
Show Index Toggle 20 comments
  •  Quick Edit
  • Peeragogy Pattern Catalog


    \label{sec:Introduction} {wrapfigure}


    \label{madison-map}“Wisconsin State University, Madison, Wis. 1879”. Inset captions describe the pictured buildings: “Ladies Hall, South Dormitory, University Hall, Assembly Halls & Library, North Dormitory, Science Hall, President’s Residence, University Farm, and Washburn Observatory.”

    This paper outlines an approach to the organization of learning that draws on the principles of free/libre/open source software (FLOSS), free culture, and peer production. Mako Hill suggests that one recipe for success in peer production is to take a familiar idea – for example, an encyclopedia – and make it easy for people to participate in building it (Chapter 1 Hill 2013). We will take hold of “learning in institutions” as a map (Figure \ref{madison-map}), although it does not fully conform to our chosen tacitly-familiar territory of peeragogy. To be clear, peeragogy is for any group of people who want to learn anything.11

    Despite thinking about learning and adaptation that may take place far outside of formal institutions, the historical conception of a university helps give shape to our inqury. The model university is not separate from the life of the state or its citizenry, but aims to “assume leadership in the application of knowledge for the direct improvement of the life of the people in every sphere” (Curti 1949). Research that adds to the store of knowledge is another fundamental obligation of the university (Curti 1949). The university provides a familiar model for collaborative knowledge work but it is not the only model available. Considering the role of collaboration in building Wikipedia, StackExchange, and free/libre/open source software development, we may be led to ask: What might an accredited free/libre/open university look like? How would it compare or contrast with the typical or stereotypical image of a university from Figure \ref{madison-map}? Would it have similar structural features, like a Library, Dormitory, Science Hall and so on? Would participants take on familiar roles \cite{corneli+crowdsourcing}? How would it compare with historical efforts like the Tuskegee Institute that involved students directly in the production of physical infrastructure (citation not found: washington1986up) Corneli 2014)?

    We use the word peeragogy to talk about collaboration in relatively non-hierarchical settings. Examples are found in education, but also in business, government, volunteer, and NGO settings. Peeragogy involves both problem solving and problem definition. Indeed, in many cases it is preferable to focus on solutions, since people know the “problems” all too well (citation not found: ariyaratneXorganizationX1977). Participants in a peeragogical endeavor collaboratively build emergent structures that are responsive to their changing context, and that in turn, change that context. In the Peeragogy project, we are developing the the theory and practice of peeragogy.

    Design patterns offer a methodological framework that we have used to clarify our focus and organize our work. A design pattern expresses a commonly-occurring problem, a solution to that problem, and rationale for choosing this solution (Meszaros 1998). This skeleton is typically fleshed out with a pattern template that includes additional supporting material; individual patterns are connected with each other in a pattern language. What we present here is rather different from previous pattern languages that touch on similar topics – like Liberating Voices (Schuler 2008), Pedagogical Patterns (Bergin 2012), and Learning Patterns (citation not found: iba2014learning). At the level of the pattern template, our innovation is simply to add a “What’s next” annotation, which anticipates the way the pattern will continue to “resolve”.

    This addition mirrors the central considerations of our approach, which is all about human interaction, and the challenges, fluidity and unpredictability that come with it. Something that works for one person may not work for another or may not even work for the same person in a slightly different situation. We need to be ready to clarify and adjust what we do as we go. Even so, it is hard to argue with a sensible-sounding formula like “If W applies, do X to get Y.” In our view, other pattern languages often achieve this sort of common sense rationality, and then stop. Failure in the prescriptive model only begins when people try to define things more carefully and make context-specific changes – when they actually try to put ideas into practice. The problem lies in the inevitable distance between do as I say, do as I do, and do with me (Deleuze 2004).

    If people are involved, things get messy. They may think that they are on the same page, only to find out that their understandings are wildly different. For example, everyone may agree that the group needs to go “that way.” But how far? How fast? It is rare for a project to be able to set or even define all of the parameters accurately and concisely at the beginning. And yet design becomes a “living language” (Alexander 1977) just insofar as it is linked to action. Many things have changed since Alexander suggested that “you will get the most ‘power’ over the language, and make it your own most effectively, if you write the changes in, at the appropriate places in the book” (Alexander 1977). We see more clearly what it means to inscribe the changing form of design not just in the margins of a book, or even a shared wiki, but in the lifeworld itself. Other recent authors on patterns share similar views (citation not found: reiners2012approach) (citation not found: plast-project) Schümmer 2014).

    Learning and collaboration are of interest to both organizational studies and computer science, where researchers are increasingly making use of social approaches to software design and development, as well as agent-based models of computation (Minsky 1967, Corneli 2015). The design pattern community in particular is very familiar with practices that we think of as peeragogical, including shepherding, writers workshops, and design patterns themselves (Harrison 1999, Coplien 1997, Meszaros 1998). We hope to help design pattern authors and researchers expand on these strengths.

    Plan of the work


    r.52 Motivation for using this pattern.

    Context of application.
    Forces that operate within the context of application, each with a mnemonic glyph.
    Problem the pattern addresses.
    Solution to the problem.
    Rationale for this solution.
    Resolution of the forces, named in bold.
    Example 1: How the pattern manifests in current Wikimedia projects.
    Example 2: How the pattern could inform the design of a future university.
    What’s Next in the Peeragogy Project: How the pattern relates to our collective intention in the Peeragogy project

    \label{tab:pattern-template}Pattern template.

    Table \ref{tab:pattern-template} shows the pattern template that we use throughout the paper. Along with the traditional design patterns components (Meszaros 1998), each of our patterns is fleshed out with two illustrative examples. The first is descriptive, and looks at how the pattern applies in current Wikimedia projects. We selected Wikimedia as a source of examples because the project is familiar, a demonstrated success, and readily accessible. The second example is prospective, and shows how the pattern could be applied in the design of a future university. Each pattern concludes with a boxed annotation: “What’s Next in the Peeragogy Project”.

    Section \ref{sec:Peeragogy} defines the concept of Peeragogy more explicitly the form of a design pattern. Sections \ref{sec:Roadmap}–\ref{sec:Scrapbook} present the other patterns in our pattern language. Figure \ref{fig:connections} illustrates their interconnections. Table \ref{tab:core} summarizes the “nuts and bolts” of the pattern language. Section \ref{sec:Distributed_Roadmap} collects our “What’s Next” steps, summarizes the outlook of the Peeragogy project. Section \ref{sec:Conclusion} reviews the contributions of the work as a whole.

    A short motivating example

    When one relative Newcomer was still in the onboarding process in Peeragogy project, she hit a wall in understanding the “patterns” section in the Peeragogy Handbook v1. A more seasoned peer invited her to a series of separate discussions with their own Heartbeat to flesh out the patterns and make them more accessible. At that time the list of patterns was simply a list of paragraphs describing recurrent trends. During those sessions, the impact and meaning of patterns captured her imagination. She went on to become the champion for the pattern language and its application in the Peeragogy project. During a “hive editing” session, she proposed the template we initially used to give structure to the patterns. She helped further revise the pattern language for the Peeragogy Handbook v3, and attended PLoP 2015. While a new domain can easily be overwhelming, this newcomer found A specific project to start with, and scaffolded her knowledge and contributions from that foundation.



    Figure 1: Connections between the patterns of peeragogy. An arrow points from pattern A to pattern B if the text of the description of pattern A references pattern B. Labels at the borders of the figure correspond to the main sections of the Peeragogy Handbook. \label{tab:core}{tabularx}

    —C— \ref{sec:Peeragogy}. Peeragogy
    How can we find solutions together?
    Get concrete about what the real problems are.
    \ref{sec:Roadmap}. Roadmap
    How can we get everyone on the same page?
    Build a plan that we keep updating as we go along.
    LABEL:sec:Reduce,_reuse,_recycle. Reduce, reuse, recycle
    How can we avoid undue isolation?
    Use what’s there and share what we make.
    LABEL:sec:Carrying_capacity. Carrying capacity
    How can we avoid becoming overwhelmed?
    Clearly express when we’re frustrated.
    LABEL:sec:A_specific_project. A specific project
    How can we avoid becoming perplexed?
    Focus on concrete, doable tasks.
    \ref{sec:Wrapper}. Wrapper
    How can people stay in touch with the project?
    Maintain a summary of activities and any adjustments to the plan.
    \ref{sec:Heartbeat}. Heartbeat
    How can we make the project “real” for participants?
    Keep up a regular, sustaining rhythm.
    \ref{sec:Newcomer}. Newcomer
    How can we make the project accessible to new people?
    Let’s learn together with newcomers.
    \ref{sec:Scrapbook}. Scrapbook
    How can we maintain focus as time goes by?
    Move things that are not of immediate use out of focus.

    An overview of the problems and solutions in our pattern language. \FloatBarrier