📖 Source→⚡ Observation·Where the pattern works/Where the pattern breaks·Interpretation ≠ Conclusion

Peeragogy in Practice

Roadmap

⏱ 5 minPAT

Motivation

This pattern shows how your group can define the scope of their project and make a realistic plan to address it. This pattern provides the backbone of our pattern language. It can be used to find a shared goal.

Context

Peeragogy has both distributed and centralized aspects. The discussants or contributors who collaborate on a project have different points of view and heterogeneous priorities, but they come together in conversations and joint activities.

Forces

Variety: people have different goals and interests in mind.

Clarity: some goals may be quite specific, and some rather vague.

Coherence: only some of these goals will be well-aligned.

Problem

In order to collaborate, people need a way to share current, though incomplete, understanding of the space they are working in, and to nurture relationships with one another and the other elements of this space. At the outset, there may not even be a coherent vision for a project – but a only loose collection of motivations and sentiments. Once the project is up and running, people are likely to pull in different directions.

Solution

Building a guide to the goals, activities, experiments and working methods can help Newcomers and old-timers alike understand their relationship with the project. It may combine features of a manifesto, a syllabus, and an issue tracker. It may be a design pattern or a pattern language [3]. The distinguishing qualities of a project Roadmap are that it should be adaptive to circumstances, and that it should ultimately get us from here to there. By this same token, any given version of the roadmap is seen as fallible. In lieu of widespread participation, the project’s Wrapper should attempt to synthesize an accurate roadmap that is informed by participants’ behavior, and should help moderate in case of conflict. Nevertheless, full consensus is not necessary: different goals, with different heres and theres, can be pursued separately, while maintaining communication.

Rationale

The group evolves from a less-sophisticated to a more-sophisticated manner of operating by using the roadmap. Using the roadmap builds a collective awareness of how things are working in practice. In the Peeragogy project our initial roadmap was a “crowdsourced” outline of the first edition of the Peeragogy Handbook. Later, it took the form of a schedule of meetings following a regular Heartbeat, supplemented by a list of upcoming deadlines. Most recently, our roadmap is expressed in the emergent objectives collected at the end of current paper. We have seen that a list of nice-to-have features created in a top-down fashion is comparatively unlikely to go anywhere! A backlog of tasks and a realistic plan for accomplishing them are vastly different things. An adaptive roadmap is an antidote to Tunnel Vision [1].

Resolution

An emergent roadmap is rooted in real problems and justifiable solutions-in-progress in all their variety and communicates both resolution and follow-through. The process of meshing varied issues with one another requires thought and discussion, and this encourages clarity. The test of coherence is that contributed goals and ideas should be actionable. The ultimate quality-control test is if it worked, i.e., did it come to pass that the task(s) the roadmap was created to achieve ended up being achieved? If all of the issues that the roadmap outlines are not resolved, the roadmap itself should be revised. Without a roadmap, we would never know.

Example 1

The Help link present on every Wikipedia page could be seen as a localized Roadmap for individual user engagement: it tells users what they can do with the site, and gives instructions on how to do it.[fn:1] someone who knows what they’re doing, there are around 30 pages listing articles with various kinds of problems, for example articles tagged with style issues, or “orphaned” articles (i.e., articles with no links from other pages in the encyclopedia).[fn:2],[fn:3],[fn:4] In 2010-2011, Wikimedia developed a strategic plan drawing on community input [2]. In 2015, a two-week Community Consultation was carried out; synthesis resulted in “a direction that will guide the decisions for the organization.”[fn:5] Community-organized WikiProjects often invite and guide involvement on A specific project.

Example 2

In a future university run in a peer produced manner, a fancy President’s Residence presumably wouldn’t be needed. Leadership would be carried out in a more collaborative and distributed fashion. However, depending on just how distributed things are, it may turn out to be useful for project facilitators to gather at a University Hall. Whereas there is strength in numbers, there is leverage in organization. This is what the Roadmap provides.

President’s Residence, University of Alabama.

What’s Next in the Peeragogy Project

If it becomes clear that something needs to change about the project, that is a clue that we might need to revise our patterns or record a new one. We can use the names of the patterns to tag our upcoming tasks.

BACK Pull together the Reading Group annotations as a plan of revision :handbook:

References

  1. David M. Dikel, David Kane, and James R. Wilson. 2001. /Software architecture: Organizational principles and patterns/. Pearson Education.

  2. Eugene Eric Kim and others. 2011. /Wikimedia Strategic Plan: A collaborative vision for the movement through 2015/. Wikimedia Foundation.

  3. Christian Kohls. 2010. The structure of patterns. /Proceedings of the 17th Conference on Pattern Languages of Programs/, ACM, 12.


[fn:1] https://en.wikipedia.org/wiki/Help:Contents

[fn:2] https://en.wikipedia.org/wiki/Category:Wikipedia_article_cleanup

[fn:3] https://en.wikipedia.org/wiki/Category:Wikipedia_articles_with_style_issues

[fn:4] https://en.wikipedia.org/wiki/Category:All_orphaned_articles

[fn:5] https://blog.wikimedia.org/2015/02/23/strategy-consultation/

⚡ Unpeeragogy · Friction · Observation

The Roadmap Is a Promise

⏱ 4 minaudit-v2roadmapplanningmilestones

Perturbatore: “What if a roadmap without owners is just a wish list with dates — and collaborative planning without individual ownership produces statements too vague to disagree with?”

A roadmap without owners is a wish list. Nothing more.

The Assumption

Groups can create shared direction through collaborative planning, where milestones emerge from collective input and commitment builds through transparent progress tracking.

Operational Reality

A roadmap without owners is just a wish list with dates.

The vault records show roadmap failures: broken promises, milestone-free planning, beautiful roadmaps that never translated to actual direction. Not because the planning was not thorough. Because roadmap creation is collaborative but roadmap ownership is individual. Someone must own each milestone.

Debian’s stable release process works because it has defined release managers and explicit policies — governance that distributes ownership along with dates. GitLab’s stewardship handbook documents who owns which decisions. Wikipedia’s ArbCom shows that shared governance without individual ownership produces contested roadmaps that satisfy no one. The cMOOC divide demonstrates that collaborative planning without structure produces direction statements too vague to disagree with — and too vague to follow.

Empirical Evidence

Resilience Cases (Confirming):

  • Debian Stable Release Process — Debian’s stable release process with defined release managers and explicit policies. Roadmap ownership along with dates enables successful collaborative planning.
  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction. Documenting who owns which decisions enables roadmap execution.

Fracture Cases (Complicating):

Operational Heuristics

Positive Boundary: The roadmap works when governance boundaries are explicit and roles are defined before planning begins — transparent policies and documented ownership enable effective collaborative planning.

Negative Boundary: Do not apply this pattern when the group exceeds informal coordination limits or when domain complexity requires specialized decision-making — shared governance without individual ownership produces contested roadmaps.

Epistemic Synthesis

Roadmap creation is collaborative. Roadmap ownership is individual. Debian has defined release managers. GitLab documents who owns which decisions. Wikipedia’s ArbCom shows that shared governance without individual ownership produces contested roadmaps. The cMOOC divide shows that collaborative planning without structure produces statements too vague to follow. A roadmap without owners is just a wish list with dates.

Evidence Status

Status Count
Confirmed cases 2
Cases under study 0
Unverified cases 0
Ambiguous cases 0

Traceability

Run: audit-v2 · Delta: 1.2 → 1.2112 (±0.0112) · Diversity D: 2

References

💬 Field Report: The Roadmap Is a Promise

Every pattern in the Handbook has been tested in the real world — and the real world usually has something to say about it. If you tried something similar, or saw it fail differently, share the story here.

Write in your native language — the browser will translate. Lowering the entry barrier is more important than choosing the "right" language. GitHub translates threads automatically so everyone can follow along.
Read how evidence is collected →

What happens after I share my story?

1. Your post appears in GitHub Discussions in the Field reports category.

2. Once a week, the project reads new threads and checks for patterns worth integrating.

3. If your story reveals a new Failure Vector, a revision to tension_index, or a sharper edge for the Perturbator — the entry gets updated.

4. The change is logged at /log and goes live on the next deploy.

Don't have a GitHub account? Here's how it works

GitHub Discussions is free. You need a GitHub account (30 seconds to create one).

Once you're signed in, click "Share your story" above. Write in your own language — the thread will be translated for everyone else automatically.

You don't need to know how to code. You don't need to know what "git" is. You just need an observation that the theory didn't match reality.

What are GitHub Discussions? →

Every pattern raises more questions than it answers.
Read the theory. Then look at what happened.