The idea described on this page helps filter RecentChanges: Pages can belong to a “cluster”; when the pages are changed, RecentChanges will only show that the cluster has changed. This is useful if the pages in the cluster discuss a topic that is not of general interest. Visitors looking at RecentChanges will only see that the cluster has changed, they will not be distracted by dozens of changes to pages in the cluster.

Thus, a PageCluster represents interest much like a page represents an idea or a concept. The pages in a cluster all belong together because if you are interested in one of them, you are probably interested in the others, too.

A PageCluster also acts as a forum for discussion: An interested group of users comes together to discuss a concept spread over several pages, without wanting to distract the casual visitors and other users.

Here is how it works:

Thus, PageClusters filter in two directions:

Clusters are RecentChanges made a DividedCommons. Several clusters could be made a UnifiedCommons, as described on UnifiedClusters.

See MeatBall:PageClusters, Oddmuse manual [1].



On ordinary RecentChanges, you will see a summary entry for the main page if clustered pages have changed. Following that link will show the main page with the clustered recent changes. Following an ordinary link to the main page will not show the clustered recent changes. To show all edits, including edits to clustered pages, use the all=2 parameter. (This means that there is no way to show traditional recent changes without clustering.)

The script only checks whether a page A belongs to a cluster when it is saved. If it does, the name of the main page B is stored as part of the change log entry for A. When the list of recent changes is produced, and the entry of page A comes up, it is replaced by a summary entry for page B, and page B is put on a list so that no other page belonging to B’s cluster will get added. The link to B is special in that it includes the rcclusteronly parameter. When page B is viewed via that link, the parameter is set, and thus the list of pages belonging to B is displayed. This again works by looking at the change log entries. Now only the pages that have B set as their cluster main page are considered. This allows for one weird thing: You can link to any page and have the list of recent changes for any other main page shown. That’s pretty useless, though.

The script does not always display the changes to the cluster pages when viewing the main page – only when the rcclusteronly parameter is supplied, or if the main page is itself in the cluster. The reason is this: The information is only stored in the change log itself. When opening a page, I don’t want to search the log itself to determine whether the current page is in fact a main page. But if the information is on the main page itself, no problem. When saving, I also don’t want to maintain pointers to the main page (or remove them from the former main page if it was changed). That seems too complicated.

If you start any page with a link to any other page, the latter becomes a cluster. Even if the link points to a non-existing main page, and even if the link has a special meaning such as “DeletedPage”. If you dislike that, you can set the deletion marker to be some text that is not a link, e.g. “Page marked for deletion.” Then deleted pages will not be aggregated.

The reason the main page is not indicated more explicitly (say by using a prefix such as Cluster:MainPage, is that such a prefix would be language dependent on a MultilingualWiki. It is already annoying enough that “DeletedPage” is language dependent. And a new syntax based on punctuation sucks.

Side Effect

When you mark a page as deleted, you actually move it into the DeletedPage cluster. The DeletedPage-cluster is obviously very important. Even if you ignore most clusters, you should watch the DeletedPage-cluster because a page from a cluster you are interested it might suddenly disappear from the clusters you are watching and end up in the DeletedPage-cluster.

Open Questions

Should pages be able to belong to multiple clusters? It might be confusing for an edit to one page to cause n clusters to show themselves on RecentChanges.

What if you are interested in all changes on a wiki? The more page clusters there are, the more separate “recent changes” you have to look at. There should be an option to turn off clustering. – AlexSchroeder

Indicating Clustered Pages

The question is: “How do you indicate that a page is clustered?”

The first line of a page is presently used to tell the wiki that the page belongs to a cluster.

There was a lot of conversation on how to use that first line. Some possibilities:

On the first line, if a WikiName

However, using the first line is considered a little kludgy. It may be better to have a new field on the edit page, similar to the existing “Summary” field.


  1. The name of the cluster must stand on its own on the first line. It must be a local link to page. The page may or may not exist.
  2. A cluster is announced using the “Cluster: “ prefix on RecentChanges. This prefix can be customized per language.
  3. new: If the cluster prefix is not defined, clustering is disabled.
  4. new: The cluster prefix will link to a page of the same name, where an explanation may be offered.


PeriPeri Implementation

PeriPeri is half-way towards my current working vision of PageClusters; see PeriPeri:RSSFeeds. The current differences from this site:

RecentChanges will eventually log clustered edits like here, but only when explicitly directed. Vandalism is handled in conjunction with PeriPeri’s StableCopy version control; see PeriPeri:RSSFeeds+StableView.


Multi-Lingual use of "PageCluster"

Some of the suggested approaches use the word “PageCluster.” “PageCluster” is English, and we’d like people who speak other languages to be able to use the system as well. We can make it so that the phrase “PageCluster,” translated to other languages, would work as well.

If we want words in another language to act like “PageCluster,” we can perform a little trick- we can make any page that redirects to PageCluster function just like “PageCluster.” So for example, “PageFaisceau” could redirect to PageCluster; Then you could use “PageFaisceau” in place of PageCluster, and everything would work as expected.

I don’t think having translations on the page is such a problem - what if someone wants PageCluster explained but they don’t speak English? They can look around on this page until they find it. Equally, if they are lucky enough to click on it in their language (likely if most pages get uni-lingual content), they will get the right version straight away.

I don’t think having communal “how this site works” pages multilingual is any worse than having many copies in different languages. – ChrisPurcell

True, but using the current mechanism, the admin of a wiki has no choice but to put the info all on the same page. This should not be necessary. When you get to eight languages or more, it will end up being a ForwardIndex anyway. – AlexSchroeder

Or it puts pressure on to keep the summary brief, which is good. Either way, this is infinitely preferable to making pages clusters magic, without any obvious linking at all to clarify what’s going on. (By this, I mean a link on the page, not in RecentChanges.) It also means one less thing to fix on Meatball when we move to OddMuse, and one less problem to explain to newbies.

Here’s another kicker. Suppose I decide to start a new page with:

 It's evil. Yep, evil. Here's why...

I have the TourBus cluster ignored, so I don’t notice that I’ve accidentally put my page into it. I get horribly confused, especially if the TourBus people are on vacation.

Incidentally, I suggest disabling the automatic [Related Changes] summary for clustered changes. It doesn’t add anything, and it distracts the eye from summary-scanning. – ChrisPurcell

I agree that your example is evil. :) There is less chance of it happening now than in the previous version, where any link used as the first word on the page would trigger clustering, so that’s better than before. It also doesn’t force a documentation paradigma on the wiki editors, which is also better than before. There remains a small amount of magic which we could counter by a small amount of syntax. Let us use triple square brackets: {{Foo}}. What do you think? – AlexSchroeder

I think it’s bad. To avoid a documentation paradigm, add support for multiple equivalents for PageClusters within the engine (hidden from view) and use the PageAlias scheme to let the community improvise in the short-term. To quote Bayle: I think adding weird wiki syntax should be avoided at all costs. A little hassle on the wiki editors arranging documentation contrasts well to a mountain of hassle explaining what those stupid brackets are there for.

It’s your engine, and I’m out of arguments. Do what you will :)ChrisPurcell

If we can’t find a good answer, then I think the best would be to remove the feature. – AlexSchroeder

I think the issue can be made more general: how does one maintain multilingual descriptions of OddMuse features? How do we make it clear that multiple languages are supported from the moment someone enters the site? Right now the banner and footer may be unintelligible. We need a general way of supporting translations, of choosing a preferred language, and of picking the right explanatory pages when links are followed.

I propose the following: PageTranslation. – ChrisPurcell

I’m using a LanguageMenu on the main page; and the main page is different for every language: SiteMap vs. √úbersicht. Thus, there is no a priori need for any bilingual pages. When the MultilingualWiki is well designed, I claim that there is no need to ever read another language but your preferred language. If you choose German from the LanguageMenu, you’ll note that it calls a different script, and even the edit note and the footer note are translated. (Some translations are missing because I am lazy, but most of it should be there.) The page cluster solution requiring all explanations to end up on the same page would be the first feature that breaks this design philosophy. (Actually this is the first time I’m formulating it that way.) – AlexSchroeder

Are you going to go with the PageCluster ‘tag’, the weird formatting, or removing clusters entirely, Alex? – ChrisPurcell

I’m currently going with what the edit note says (and described above): “If the first line contains nothing but a local link, then the page will belong to that Cluster.” – and we’ll see how it goes: An experiment. And after a few days we’ll see whether it is good enough or not. One thing recent changes in the clustering mechanism have shown that whatever ideas we have, most of them are very easy to implement, so we might as well just try them (reduce ProcessOverhead). – AlexSchroeder

I’ll get on with using it a bit, then. – ChrisPurcell

Holey Moley, I think I’ve just understood PageCluster. Not just intellectually, but in terms of how we can actually use it. Before, I was like, “eh…” But now, it makes a lot of sense to me.

I think the key was realizing that PageCluster tech makes the RecentChanges of wiki organize just like topic boards (example: on the Internet.

So, now that I get it, I have some ideas:

I think if it were just like this 15 day thing, that we’d do it with much greater regularity.

Right now, I don’t page cluster because:

(That’s not to say these are good reasons. I am just talking from a feeling perspective. Maybe I should just BeBoldAndCluster?.)

What I would do, if I felt comfortable with clustering, would be to make some of the following clusters:

I also think that PageCluster combined with 15-day auto-deletes (still archived- this isn’t about ForgiveAndForgetInSoftware) could be ultra powerful. If I could invoke a new page within the context of a PageCluster, intended to be deleted upon the death of the PageCluster- that could end up very powerful. You could have the positives of a ForestFire, without the negatives, and only the people involved would ever see it. You could even make clone pages, automatically deleted after discussion, to avoid defacing the “actual” page. So, for example, you make LessRedundancyClone?, to talk about LessRedundancy, without disturbing the “actual” copy. When conversation is over and conclusions are reached, you rework on the original “LessRedundancy” page.

Mmm… Lot of coolness you can do with this.


I’ve done some work in reworking this page. There’s still a lot more to do. I’m not working on this, immediately.

I suspect a lot of reworking this just consists of moving text verbatim to a new ExperimentalTechnology page.


We may want SiteMaintenanceCluster?, a cluster that all the categories would go into, as well as other “site maintenance” stuff.

Maybe we should give it a more colorful name: “TheSlavePits?,” or something like that. (I do suspect that, one day, there will be PeerReview duty..!)


A minor edit adding a page to a cluster should move the last major edit there. This would allow us to create clusters when fires become apparent without losing the last-modified date or the (probably useful) summary, nor leaving RecentChanges higgledy-piggledy.

Adding pages to a cluster should provide some extra warning for people not interested in the cluster, because as it stands, you can easily steal pages into your cluster. (“I’ve been silently accumulating all them pages in WikiPatternLanguage, how many of you noticed?” ;)) Some ideas are mentioned above, but we should rethink them carefully. For example, adding a note to a cluster when a page was removed doesn’t help us when an unclustered page is moved into a cluster. And for the people working on the infrastructure (eg. me), we’ll have to think about ways of putting the info in the logs… – AlexSchroeder

I have to wonder whether it’s worth storing that information - you’d need to store it indefinitely, and it’s such a waste of attention. Any system can be abused. Perhaps it’s better as it is? – ChrisPurcell

I’ve made ClusterVisualization to talk about the specific visualization issues that have come up around PageCluster.LionKimbro

I haven’t but taken a peek to it, but Ifeel like witing. Nice cluster of yours here. How come I do not get a note but that it jumps up here and now of what goes on in here. You are constructing a tree. Good. RecentNearChanges? Recentchanges ClusterRecentChanges? SubClusterRecentCheanges?… Maybe even MetaNearRecentChanges? a day. At least: There is a balance on every level. The amount of pages, subpages, subsubpages and so on covered, that is the ancle of your view, the focus of the objective of your camera, and the precision of the information the respective recent changes provide, that is how many details your foto shows. Further up the view is wide, precision is low, 35 mm focus, waydown the view is narrow, precision is high, 108 mm focus. And now: Wiki is dynamic. Someone could see the summary of a cluster in the main recent changes change three times during an hour of decent WikiWork? and know, this is lively right now. Rather creating a bit of information overload. BeBold also with the engine. 040117 00:29 – MattisManzel

I find clusters to be a bit annoying, especially when I’m interested in what’s inside. I suppose I’m not annoyed at all by clusters I don’t care about.

What if the system could keep track of when I last edited a page in a cluster and use that date to determine if that whole cluster should show on RecentChanges for me or not? Thus when I edit a page in a cluster, I’m “subscribed” to that cluster and it’s then invisible on RecentChanges for me until my subscription expires (a day, a week, two weeks?). No idea how hard this would be to impliment without log-ins, but thought I’d mention it.

I second that. Clusters are freakin’ annoying, the way you have to click into them. (That said, I think they’re a great way for us to cordon off sections of RecentChanges. Just not if you happen to be in them.)

We’ve seen an accidental clustering of the MindBodyProblem page, which used to start with the link “MindBodyProblemArticle” alone so that the page only has dicussion left in it. I’m assuming the intent wasn’t to form a cluster, but to seperate a lengthy discussion from the article (sigi made the change, and I’m not sure he’s that familiar with the cluster “feature”).

  • no, i was not familiar with :)

So, clusters do get in our way. I wonder if one way of handling this wouldn’t be to add a rule: only display the cluster thing in recent changes if more than one page in that cluster changed today. The goal of the “cluster summary” in recent changes is to prevent multiple changes from flooding the recent changes and distracting everybody., so maybe it should only fire if there actually is a flood. Like that, “accidental” clustering would go unnoticed (unless several pages fell into the same accidental cluster, which is quite unlikely and easy to fix), and it wouldn’t disrupt the way clusters we already have work.

But then, we may be shifting to a community programmable CommunityRepository in the near future, so it may not be worth worrying about this.

There seems to be a problem with the DeletedPage cluster. Weird. Now that I think about it, however, I think that page clusters have been mostly annoying. I think we should get rid of them.

(Update: Hopefully the DeletedPage cluster problem has been resolved.)

for better or for worse :), why not making a rc-tree?


  • A
    • B
      • D
    • C
  • E

if you click on A, you get the rc of (A (B (D)) (C)) .
if you click on B, you get the rc of (B (D)) .
if you click on C or D or E, you get the rc of C or D or E .

in A is a link to B and to C, in B is a link to D .
so, all we need is a hint in B and C (first (last) line): “back to A”
and in D: “back to B” .
in case, we need the first line and give up “back to”, it’s exactly the cluster name syntax .
so, each page, which comes out from another page, has to have a rc-tree name .

I think the problem is the recent changes at the end of the page. It should start with the recent changes.

@sigi: Interesting. Maybe even the community can commonly “shape” this rc tree, kinda create a map of the tubes and chambers in the hive and this information is added to the wiki-net-feed. Not only seeing who is watching the activities in your community but also seeing rightaway how this watching community is internaly organized, what tubes and chambers they have. I’m a bit of looking into the future here.

I am totally against the rc-tree. In a way, we already have a simple form of it: The current page clusters are like a two-level implementation of such a tree. And it sucks, as far as I can tell. It makes following Recent Changes harder.

Here’s a different solution: We shall use tags. We abolish page clusters. We tag pages. If there is a tag we care about, we bookmark the recent changes filtered by that tag.

Example: Visit the TagCloud, click on a tag, click on View changes for these pages.

Looks good enough for me!

it’s a good idea . but not for the recent changes .
if you make a new page, you perhaps tag it with xxx . that’s good for you, but not for me .
even if there is a list with some common tags (hopefully not 1000 as in TagCloud) and we learn to handle correctly, then you must at least click in the list and that’s quite the same as with the rc-tree .

That’s true, but just as with the current system, you can bookmark the result. So that’s no drawback.

But there are two benefits the current system doesn’t have:

  1. You can bookmark one link for multiple tags, whereas you can only bookmark one page cluster.
  2. The default is to show complete recent changes without clustering. The current system is annoying in this respect.

Page clusters were removed from CommunityWiki. See 2006-08-17 Feature Karma for more info.


Define external redirect: ClusterRecentChanges LessRedundancyClone WikiWork SubClusterRecentCheanges MultiLingualDiscussion WikiHomePages TheSlavePits RecentNearChanges SiteMaintenanceCluster InterWikiTechDiscussion BeBoldAndCluster MetaNearRecentChanges

EditNearLinks: PageClusters TourBus MultilingualWiki StableView StableCopy FeatureKarma PeriPeri FooBar PeerReview FrontLawn ForestFire WebLogs OddMuse ForgiveAndForgetInSoftware WikiName


The same page elsewhere: