Learning patterns/Learning from patterns

Learning patterns
problemWe need to make it easier for people to capture and share what they learn when they perform mission-aligned activities.
solutionEncourage movement partners to capture important lessons in "learning patterns" -- concise, usable descriptions of common problems and their solutions. Organize these patterns into a library so people can find patterns that are relevant to the projects they are working on. Encouraging people to create new patterns, and to endorse and expand existing ones, turning the library into a living, collaboratively-created resource for our entire movement.
creatorJtmorgan
endorse


What problem does this solve? edit

In order to demonstrate that our activities have impact, to fail better, and further our mission, we need to make it easier for people to document, find, and use information about effective and ineffective strategies for performing mission-aligned activities.

The kinds of activities Wikimedians pursue, and that the Wikimedia Foundation supports through grants, are nearly as diverse as the Wikimedia movement itself. From volunteer collaborations, to grant-funded projects, to established programs and the efforts of movement partners, we currently support a wide variety of online and offline activities aimed at supporting our projects and achieving our strategic goals--increasing participation and reach, improving quality, stabilizing infrastructure and encouraging innovation.

The Wikimedia Foundation supports many of these activities by providing grants. However, it takes more than money to organize, execute, and evaluate a successful project. For instance, leading an editing event such as a workshop, conference or edit-a-thon involves many different skillsets, considerations, and tasks: advertising your event to the right people, distributing roles and responsibilities effectively within the project team, and structuring the event itself so that participants get the most value.

Dozens of these events are held every year, led by teams all over the world. Many of these teams are putting on an event for the first time, while others have extensive experience. Many groups gather extensive data on the activities they lead: what the activities involve, who participates, and what the outcomes are. However, it is not always clear how to use that data to demonstrate the impact of an activity on our movement's strategic goals. And although we do a good job of capturing important lessons from our activities--what we did, what we learned, and what we would do differently next time--those documents are often scattered across wikis, buried in archived reports, written in different languages, or left unfinished.

It's not that we haven't captured important information about what works (and what doesn't) for editing events and other activities. If anything, we have an information glut. But this information can be hard to find. And even when you find it, it can be hard to judge whether the "lessons learned" from a previous activity are applicable to your own activity.

The lack of accessible, usable information on how to perform and evaluate mission-aligned activities has two major consequences:

  • Community members who are performing an activity for the first time lose out on an opportunity to benefit from the expertise of others who have performed similar activities in the past.
  • Our movement as a whole loses out on an opportunities to learn which activities have the greatest positive impact on our strategic goals, and under what circumstances those activities are most effective.

Taken together, these challenges makes it difficult for people to find the information they need to do what they want to do better. It also makes it nearly impossible to synthesize all of these different outcomes, lessons learned, and research findings into a coherent set of recommendations or evaluation criteria. Furthermore, the knowledge that our reports may not be read by anyone can be demoralizing: it make the prospect of writing another project report, blog post, tutorial, or FAQ seem like a pointless chore, rather than an opportunity to make a valuable contribution.

We need a more usable and visible way of communicating key lessons learned. This will help us teach one another, avoid wasting our energy reinventing the wheel or making the same mistakes over and over, and assure that promising new ideas don't get lost.

What is the solution? edit

Each pattern describes a problems which occurs over and over again in our environment, and then describes the core of the solution to that problem, in a way that you can use this solution a million times over, without ever doing it the same way twice.

We can begin to address this problem by documenting our key lessons in a common format that is easy to read and write, that is flexible enough to use for many different kinds of activities, and that allows you to capture many different kinds of tips, advice, effective strategies and important considerations. One format that fits these criteria is the design pattern. Design patterns have been used in fields such as architecture, computer programming, education, to document common solutions to recurring problems.

For convenience and clarity, each pattern has the same format. The headline gives the essence of the problem in one or two sentences. After the headline comes the body of the problem. It describes the empirical background of the pattern, the the evidence for its validity, the range of different ways the pattern can be manifested, and so on.

Then is the solution--the heart of the pattern--which describes the field of physical and social relationships which are required to solve the stated problem, in the stated context. The solution is always stated in the form of an instruction--so you know exactly what you need to do, to build the pattern.

To create a design pattern, you first state a problem--which may be an issue you have encountered, or a specific goal you want to achieve--and then describe the solution that problem. You can also provide additional information such as example scenarios where this problem tends to crop up, evidence for why the proposed solution is effective, and special considerations to keep in mind when implementing the solution. There are many different ways of formatting a design patterns, but all patterns follow this basic structure. Patterns can be long (like this one!) or short. They can provide common sense advice or detailed step-by-step instructions. They can be highly context-specific, or apply to a wide variety of contexts.

Patterns can also be related to other patterns. A group of design patterns that provide guidance within a specific domain is called a pattern library, or a pattern language. Similar patterns, or patterns that are most effective when used with other patterns, can be hyperlinked to one another so that people can easily browse many common problems & solutions that are relevant to their activity, and so that new patterns can easily be integrated into the library.

Does this method for organizing related content sound familiar? It should. The first wiki was a pattern library.[3]

Learning patterns edit

We refer to design patterns that can be used to capture the kinds of key lessons that are most important for people who perform mission-aligned activities within the Wikimedia movement as learning patterns. Learning patterns are wiki pages that use a simple page layout in order to make it easier for people to understand the purpose of the pattern and the context in which it applies without having to read the whole thing. Some elements of the page layout (such as the infobox) are also used to categorize patterns according to the kind of activity they relate to (events, online engagement initiatives, group collaboration, etc.), and to make it easy for bots to create summaries of each pattern that can be displayed in dynamic lists on portals and other on-wiki collaboration spaces.

This page is an example of a learning pattern, albeit a rather meta and long-winded one.

Considerations edit

Advantages of learning patterns edit

  • Patterns are usable. An effective pattern is written so that someone can quickly understand the problem (or goal) that the pattern addresses, and how a solution can be achieved. The primary headings of the pattern ("What is the problem?" and "What is the solution?") prompt people to think about the key lessons that they wish to share in terms of how others can benefit from it. Additional sections of the pattern are optional: they can be used to provide references to documents (such as grant reports) that back up the advice given in the pattern, provide specific considerations that people should keep in mind when using the pattern, or even provide useful multimedia resources such as images, diagrams and videos.
  • Patterns are easy to make. We provide a simple workflow with clear instructions to guide people through the pattern-making process. Only the first part of the pattern is required, so someone can add a new pattern quickly and then they (or someone else!) can come back and fill in other details.
  • Patterns are easy to read. All learning patterns follow a consistent format, making it easy to browse through multiple patterns and find what you want.
  • Patterns provide evidence. Patterns link to sources of evidence such as project reports, external resources, examples, and research studies. This makes it easier for the person reading the pattern to evaluate the quality of the advice contained in the pattern, and whether it is suitable for them.
  • Patterns are collaborative. No one owns a pattern: the person who created it is just the first person to endorse it. Others can come along and add more detail, examples, evidence, related patterns, or media. If they think the pattern offers good advice, they can endorse it themselves.
  • Patterns are scalable. People can add a pattern about anything they want. If the pattern doesn't fit into any existing categories in the library, they can create a new one. If there are not yet any related patterns, others will see the category may be inspired to add them. This structure allows the library to grow naturally in the areas where work is happening, without the need for a rigid taxonomy. If someone creates a pattern that duplicates an existing pattern, the version that is most complete, or that has been endorsed by the most people, can be surfaced more prominently than the less complete pattern.
  • Patterns are fun.[citation needed] Some people enjoy making patterns. :) They can be kind of cheeky in tone, even if they provide serious lessons. Images and diagrams that make the pattern more visually compelling also makes the pattern more useful. People enjoy sharing their knowledge more when they believe that it will benefit others. The visibility of the learning patterns library gives them confidence that their contribution will be seen and used. If grantees are given the option of fulfilling some of their reporting requirements by adding patterns, they may find that a more interesting and valuable way of reporting what they learned.
  • Patterns are a safe way to discuss failures. People may be hesitant to discuss the decisions they made that didn't pan out, or the things that went wrong with their project because they are concerned that by admitting specific mistakes, they are opening their entire project up to criticism or dismissal. This is especially true when someone is reporting their activities to a funding agency. Writing up a mistake as a pattern shifts the focus from what a specific person or project did to what works and what doesn't work for particular sorts of projects.
  • Existing resources can be converted to patterns. Our pattern library can be expanded by creating patterns based on things we've already learned. For example, one of the key lessons learned from this case study was converted into Grants:Learning patterns/Photographic evidence. Other key points from the "Lessons learned" section of hundreds of grant reports could be converted into patterns as well, making both the important lessons and the reports those lessons are drawn from easier to find and use.
  • Patterns are translator-friendly. Patterns are written in a common format, and are generally succinct and well-structured, making them potentially easier to translate than longer more complex documents. Different language versions of the same pattern can be made available in the same location using existing translation templates.
  • ...

Disadvantages of patterns edit

  • Problem/solution format. Not everyone thinks of key lessons in terms of problems and solutions.
  • Not very effective on their own. Although you could conceivably create a pattern that describes how to perform a whole activity, most patterns only describe a small piece of a larger puzzle. A single pattern on how to phrase survey questions, for example, is not very useful without a set of related patterns that describe the kinds of survey questions to ask, how many people to survey, and how to get them to fill your survey out. A small, fragmentary pattern library is probably not very useful to anyone.
  • "Pattern" is jargon. The word pattern is kind of jargon-y. It requires explanation. Other terms may be simpler to understand at the outset, although using a general term that means something different in other contexts may result in people not understanding what makes a pattern different from, say, a report or a tutorial. That could mean that people don't write very effective patterns.
  • ...

Examples edit

Patterns contain an example (a diagram, picture, written scenario, etc.) which shows an implementation of the solution, and calls out its main components. Examples of pattern libraries:

See also edit

Related patterns edit

This section is for putting links to other design patterns that are on the same topic as this one, that complement it, or that expand on it. A simple bulleted list of wikilinks is a good format. A hatnote template could also be used here.

External links edit


References edit

  1. Christopher Alexander, "A Pattern Language", pp. xi
  2. Christopher Alexander, "A Pattern Language", pp. xi
  3. WikiWikiWeb - Wiki History