How to Run a Shared Course Wiki for Cohort-Based Learning with Learnomy and WB Member Wiki

A cohort moving through the same material on the same schedule has something a self-paced course never gets: forty or sixty people hitting the same confusing lesson in the same week. That’s a problem if nobody captures it. It’s an asset if someone does, because the student who finally understood the tricky concept on Tuesday can explain it in a sentence that helps the other thirty-nine people who hit it on Wednesday.

A structured course, the kind Learnomy delivers well, is instructor-authored and intentionally fixed: lessons, quizzes, a syllabus that doesn’t change mid-cohort. A shared wiki is the opposite by design, a living layer the cohort writes together: a glossary of terms as the class actually uses them, a running list of resources someone found useful, worked-through study notes on the lesson that didn’t quite click from the slides. Neither replaces the other. The course teaches; the wiki is what the cohort remembers.

This guide covers one specific pairing: Learnomy for the structured course and cohort layer, WB Member Wiki for the collaborative knowledge base that layer needs alongside it. If you already have a generic community wiki running, this is a different problem, scoping a wiki to one cohort’s lifecycle rather than running one open-ended site-wide reference. Here’s the full setup, from cohort creation to permissions to keeping a student-written glossary from drifting into noise.

Table of Contents

• Why a Cohort Needs a Wiki, Not Just a Course
• What the Research Says About Learning Together
• Step 1: Set Up the Learnomy Cohort
• Step 2: Pair a Cohort-Scoped Space in WB Member Wiki
• Step 3: Configure Edit Permissions for the Cohort
• Step 4: Use WikiLinks for a Living Glossary
• Step 5: Moderate Without Killing Participation
• Real-World Scenario: A Coding Bootcamp Cohort
• What This Costs
• Common Mistakes
• FAQs

Why a Cohort Needs a Wiki, Not Just a Course

A course page is written once, by the instructor, before the cohort starts. It can’t absorb what actually happens once real students hit it: which explanation clicked, which analogy didn’t land, which external article someone found that explains the hard lesson better than the official one. A wiki can, because anyone in the cohort can open it and add a line.

This is a different problem from the one a general community wiki solves. A site-wide member wiki (we’ve covered that setup separately) is open-ended: any member, any topic, no end date. A cohort wiki is scoped and time-bound in a way that actually makes it easier to run well. You know exactly who should be writing in it, which is everyone currently enrolled in that specific cohort. You know roughly what it should cover, because it maps to the syllabus. And you have a natural seeding moment: day one of the cohort, when the instructor drops in the first ten glossary terms and the wiki stops being an empty page.

The payoff compounds if you let it. A single cohort’s wiki is useful for those students during those eight or twelve weeks. But if you don’t wipe it between cohorts, and instead let the next cohort start from what the last one built, the glossary and resource list get better every single run instead of starting from zero every time you open a new cohort. That turns a one-off study aid into a course asset that improves itself.

Step 1: Set Up the Learnomy Cohort

Cohorts are a Learnomy Pro feature ($149/year), built for exactly this situation: a group of students enrolled together, moving through the same course on the same schedule, with enrollment scoped to a start and end date rather than open-ended self-paced access. Create one from Learnomy > Cohorts > Add Cohort, attach it to the course, and set the start and end dates that match the actual run, not just a vague “8-week program” label.

The reason this matters for the wiki pairing specifically: the cohort record is what tells you who should have write access to that cohort’s wiki space and when that access should start and stop mattering. A student enrolled in the “React Fundamentals - Spring Cohort” shouldn’t be editing the glossary for a cohort that ran eight months earlier, and a cohort that completed in November doesn’t need new edits in February. Learnomy’s cohort membership list is your source of truth for that scoping, even though the wiki permissions themselves are configured in WB Member Wiki, covered next.

Name cohorts in a way a human can match against a wiki category without guessing, “Python for Data Science - June Cohort” rather than “Cohort 14.” You’ll be creating a wiki category or group with a parallel name in the next step, and the two should be obviously the same thing to anyone looking at either system.

Step 2: Pair a Cohort-Scoped Space in WB Member Wiki

WB Member Wiki doesn’t know anything about Learnomy cohorts natively, there’s no built-in integration between the two plugins, and that’s fine. The pairing is a structural one: you create a wiki space scoped to the cohort, not a code integration. Two ways to do that depending on how your site is organized.

If your community runs on BuddyPress or BuddyBoss alongside Learnomy, the cleanest approach is a BuddyPress group per cohort (or per course, if cohorts are short-lived and you’d rather keep one group running across several runs), with WB Member Wiki’s group-level wiki feature giving that group its own wiki section separate from the site-wide one. Each cohort’s students join the matching group when they enroll, and their wiki section is automatically scoped to exactly the right audience, nobody has to remember a separate permission list.

If you’re not running BuddyPress, or you want the cohort wiki visible without a group wrapper, create a top-level wiki category named to match the cohort (“Python for Data Science - June Cohort”) and keep every page for that run under it. This is less automatic than the group approach, since you’re managing membership as a flat permissions list rather than inheriting it from group membership, but it works on any WordPress site and doesn’t require BuddyPress as a dependency.

Either way, seed the space before day one. An empty wiki page the moment a cohort starts reads as “nobody expects you to use this.” A glossary with the first ten terms already defined, plus a resources page with two or three links the instructor already trusts, reads as “this is where the cohort works,” and new contributors edit an existing page far more readily than they start one from a blank screen.

Step 3: Configure Edit Permissions for the Cohort

The right default for a cohort wiki is more open than a site-wide community wiki would use, because the audience is already pre-vetted: everyone with access enrolled in and is paying for the same course. Set editing open to all logged-in members of that cohort’s group (or, for the flat-category approach, to the role you’ve assigned enrolled students), with page creation available to everyone rather than gated to a “trusted editor” tier the way a public community wiki might. A cohort of 20 to 40 paying students drilling through the same material for eight weeks is a low-risk editing population; the governance a large open community needs is overkill here.

What you do want locked down is structural, not editorial. Lock the top-level glossary and resources index pages themselves (title, category structure, the skeleton the cohort fills in) to instructor or moderator roles, so no student accidentally deletes the page everyone else is contributing to. Leave the content within those pages, and any sub-pages the cohort wants to create, open to the whole cohort.

Role	Edit existing pages	Create new pages	Lock or delete
Enrolled cohort student	Yes	Yes	No
Teaching assistant	Yes	Yes	Lock only
Instructor / admin	Yes	Yes	Lock and delete
Alumni (post-cohort)	Optional, read-only is common	No	No

That last row matters if you’re carrying the wiki forward between cohorts. Once a cohort finishes, decide deliberately whether alumni keep edit access (useful if you want them correcting mistakes they now understand better in hindsight) or move to read-only (simpler, and prevents an old cohort’s edits colliding with the current one’s). Role-based permissions, watchlists, and edit locking are Developer-tier features ($79/year, five sites) and above, Personal tier ($49/year, one site) covers front-end editing and revision history but not the granular role controls this setup leans on.

Step 4: Use WikiLinks for a Living Glossary

This is where the pairing earns its keep over either tool running alone. Type [[Term]] anywhere in a wiki page and WB Member Wiki turns it into a link automatically, blue if the glossary entry already exists, a different color if it doesn’t yet, and clicking an unwritten link creates the stub page ready to be filled in. For a cohort glossary, that single mechanic solves the two hardest problems in collaborative study notes: consistency and discoverability.

Consistency, because once “gradient descent” has a glossary page, every student writing lesson notes who types [[Gradient Descent]] links straight to the same shared definition instead of re-explaining it their own way three different times across three different pages. Discoverability, because a student who writes [[Backpropagation]] in their notes before that term has a page creates a visible, color-coded signal that the term needs defining, without anyone having to maintain a manual “terms we still need to cover” list by hand.

Practically, this means you want a dedicated glossary index page per cohort from day one, even if it starts with only three or four terms the instructor seeds. As lesson notes and study-guide pages reference terms with [[WikiLink]] syntax instead of plain text, the glossary grows from what the cohort is actually confused about and actually discussing, not from a list an instructor guessed at before the course started. By week four of an eight-week cohort, the glossary usually reflects the real shape of where the class struggled, which is more useful to the next cohort than a glossary written in advance ever could be.

Step 5: Moderate Without Killing Participation

A cohort wiki needs less moderation machinery than an open community wiki, not more, precisely because membership is small, known, and time-boxed. The instructor or a teaching assistant can realistically watch every page in a 20-to-40-person cohort’s wiki without a formal review queue. Revision history with one-click restore is the real safety net here: if a student adds something wrong or sloppy, fix it with a revert, not a confrontation.

Where moderation actually earns its weight is quality, not abuse. Watch for glossary entries that are technically correct but too terse to help anyone who didn’t already understand the term, and nudge the original contributor to expand rather than rewriting it yourself, since a student’s own explanation in their own words is usually what helps the next confused student most. Use watchlists on the core glossary and resources index pages specifically, so the instructor gets notified when either changes rather than having to check daily.

The failure mode isn’t vandalism, it’s silence. A cohort wiki that nobody edits in week one usually stays empty through week eight. Seed it, point at it from inside the lesson itself (“add this to the glossary if the explanation above didn’t click for you”), and the first few real contributions tend to pull the rest of the cohort in behind them.

At the end of the cohort, do one deliberate pass: archive or merge pages that were specific to a one-off confusion no longer relevant, keep the glossary and resource list intact, and decide the alumni access question from Step 3 before the next cohort starts. A wiki that’s reviewed once per cohort stays usable far longer than one left to accumulate indefinitely.

Real-World Scenario: A Coding Bootcamp Cohort

A 12-week part-time coding bootcamp runs cohorts of roughly 30 students through the same curriculum on Learnomy, each cohort scoped with its own start and end date so enrollment, drip pacing, and certificates stay tied to that specific run rather than leaking across cohorts. Alongside the course, each cohort gets its own BuddyPress group with a WB Member Wiki space: a glossary, a “gotchas” page for environment setup issues that trip people up every single cohort, and a resources page for outside tutorials and articles students found useful.

Week one, the instructor seeds the glossary with 15 core terms and the gotchas page with the three setup issues that come up in literally every cohort (a Node version mismatch, a Git authentication error, an editor extension conflict). By week three, students are adding terms on their own as they hit them in lessons, writing short definitions in [[WikiLink]] syntax that connect back to the glossary, and one student who spent an evening debugging a tricky CORS error adds a full walkthrough to the gotchas page that saves the next three students who hit the same wall from repeating that evening.

By the cohort’s final week, the wiki has roughly 40 glossary terms, a gotchas page that’s grown to cover a dozen real environment issues, and a resources page with 20-odd outside links students vetted themselves rather than ones the instructor pre-selected. When the next cohort starts eight weeks later, the instructor doesn’t start from a blank wiki, they copy the structure forward, clear out anything genuinely specific to the prior group, and the new cohort starts with a gotchas page that already covers the first two weeks of setup pain the previous group discovered the hard way. Six cohorts in, the gotchas page alone has become one of the bootcamp’s most-cited resources, something no single instructor sat down and wrote, but the collective output of 180 students across a year and a half of actually hitting the same real problems.

What This Costs

For the setup described in this guide, the practical minimum is Learnomy Pro for cohorts ($149/year) plus WB Member Wiki Developer for role-based permissions and edit locking ($79/year), a combined $228/year for a tutoring business, bootcamp, or training program running cohort after cohort on its own domain, with no per-student or per-seat cost on either side as enrollment grows.

Common Mistakes

• Launching the cohort wiki empty. A blank page on day one signals that nobody expects it to be used. Seed the glossary and resources index before students arrive.
• Running one giant wiki across every cohort ever enrolled. Without a cohort-scoped group or category, pages from different runs blend together and the glossary stops reflecting any specific cohort’s actual pace.
• Forgetting to decide alumni access. A finished cohort’s students still editing a live current cohort’s pages, or losing all access the moment the course ends, are both deliberate choices you should make, not defaults you stumble into.
• Treating the course content and the wiki as one thing. The syllabus is instructor-authored and shouldn’t be student-editable. Keep the wiki clearly separate so nobody accidentally edits a graded lesson.
• Not carrying the wiki forward. Wiping the wiki between cohorts throws away the exact compounding value, a glossary and gotchas page that get better every run, that makes this setup worth the extra plugin in the first place.
• Over-moderating a small, known audience. A 30-person paying cohort doesn’t need the review queue a public community wiki needs. Open editing plus revision history is usually enough.

Frequently Asked Questions

1. Is there a native integration between Learnomy and WB Member Wiki?

No, and you don’t need one. The pairing is structural: scope a WB Member Wiki group or category to match each Learnomy cohort, rather than relying on a built-in sync between the two plugins.

2. Do I need Learnomy Pro for this setup?

Yes, cohorts are a Pro feature ($149/year). The free tier handles unlimited courses and students but doesn’t have scoped, dated cohort enrollment, which this pairing relies on.

3. Which WB Member Wiki tier do I actually need?

Developer ($79/year, five sites) at minimum, since role-based permissions and edit locking, both used to scope editing to the current cohort, are Developer-tier and above. Personal ($49/year) covers front-end editing and revision history but not the granular role controls.

4. Does the wiki need BuddyPress to work this way?

No. BuddyPress groups make the group-level wiki and automatic membership scoping easier, but a flat wiki category matched to the cohort name works on any WordPress site without BuddyPress installed.

5. What happens to the cohort wiki after the course ends?

That’s a decision you make deliberately, not a default. Common options are read-only access for alumni, full archiving, or carrying the glossary and resources forward as the seed for the next cohort running the same course.

6. Can two cohorts running the same course at different times share one wiki?

You can structure it either way. Separate cohort-scoped wikis keep each run’s notes distinct and timestamped; a single ongoing wiki that carries forward between cohorts compounds faster but blends the specific pace of any one run.

7. How is this different from just using the Learnomy discussion or Q&A feature on a lesson?

A discussion thread is chronological and tied to one lesson. A wiki page is continuously editable, cross-linked through WikiLinks, and organized as reference material, better suited to a glossary or study guide meant to be looked up later, not just read once in order.

8. Will students actually use a wiki instead of just asking in chat or a forum?

Seeding it matters more than the tooling. A wiki with the first ten terms already defined, plus an instructor who points to it from inside lessons (“add this if the explanation didn’t click”), gets used. An unseeded, unmentioned wiki usually doesn’t, regardless of the plugin.

9. Can I restrict the glossary’s top-level structure while leaving content open?

Yes, page-level edit locking lets you lock the index or category pages themselves (so the skeleton doesn’t get deleted) while leaving individual glossary entries and sub-pages fully open to cohort students.

10. Does this work for a self-paced course instead of a cohort?

It’s weaker without a cohort. The value here comes from many students hitting the same lesson in the same week and writing about it together. Self-paced students are spread across months, so the wiki never gets the concentrated, simultaneous confusion that makes a glossary grow quickly.

Summary

A structured course and a collaborative wiki solve different problems, and a cohort is exactly where you want both running at once. Learnomy’s cohorts keep the syllabus, pacing, and enrollment scoped and instructor-controlled. WB Member Wiki, scoped to that same cohort through a group or category rather than any built-in sync, gives the students in it a place to build the glossary, gotchas list, and resource page the official lessons were never going to write for them.

Seed it before day one, keep editing open to the cohort rather than locked down, let WikiLinks do the work of surfacing what still needs defining, and make a deliberate choice about what carries forward when the cohort ends. Do that across a few runs of the same course and the wiki stops being a nice-to-have add-on and starts being the thing returning instructors and repeat students actually reference first.

Interesting Reads:
How to Build a Collaborative Member Wiki on BuddyPress
How to Build a Test-Prep Academy with Learnomy