CommunityWiki is experimenting with PageClusters, and hopefully will discuss better ways of applying it to raise barns as well as mere technical modifications.
Page clusters are groups of pages belonging to a main page. Edits to the clustered pages are logged on the cluster's main page, invisible to RecentChanges users; they are also logged on the cluster's main page. (The main page itself may or may not be in its own cluster, so edits to it may or may not be invisible to RecentChanges.)
A page is marked as belonging to a cluster with some pattern-matching magic, say by putting a link to the main page as the very first thing on the page (as DeletedPage works; this turns DeletedPage into a cluster of deleted pages for review).
These are the main difference to SubPages:
The visible effects on RecentChanges of clustering a page:
Here is a list of benefits page clustering has over similar ideas such as FractalWiki or ParallelWiki.
PageClusters may be a solution to an illusory problem. It can be emulated by closely-linked Wikis, and its effects can be reproduced by other means (e.g. FractalWiki). However, it is also rather elegant and (hopefully) hassle-free to use, especially with one or two of the following extensions. -- ChrisPurcell
Instead of removing clustered changes entirely from RecentChanges, simply note that a cluster has changed (aggregating the individual pages), and link to the cluster's main page. This involves the whole community in every cluster, but lets people ignore clusters, or catch up on ones they haven't had time for recently. RecentChanges now resembles a forum.
One issue with this is how it should interact with an update to a page in multiple clusters.
OddMuse enables this variant.
As an extension to cluster clustering, provide options for each cluster to inline or remove it for an individual viewer, ideally semi-permanently via cookies.
Clusters can be used as weblogs, especially with RSS feeds provided for each cluster. Overriding the name, date and overview of a page (as displayed on the cluster) helps this, but raises issues of security if changes to pages are masked by the overriding date. PeriPeri uses this system.
Another possible extension: use the clustering mechanism to implement password-protected (or e.g. IP-bound) clusters of pages specific to a project. Instead of marking the root as a vanilla page cluster, use e.g. PasswordCluster. This would have all the effects of normal clustering, plus a password would be needed to view pages in the cluster.
This system is not advocated for a fully open Wiki like Meatball.
One nice advantage of cluster marks is that we do not put irrelevant information first, e.g.
need not be the first line, but can remain at the end of the DocumentMode section at the top as the category markers currently do.
Another nice advantage of cluster marks is that a page can belong to multiple clusters.
PageCluster: CategoryWikiTechnology CategoryInformationVisualization
Clusters may then also be namepages.
PageCluster: CategorySoftSecurity SunirShah
Getting us closer to SubscribedChanges with decent FeatureKarma. Issues with multiple clusters include how to render RecentChanges, but then again, one might claim that RecentChanges requires heavy redesign as it stands.
They make RecentChanges harder to read (multiple clicks and page loads) and if they are meant to contain current discussion, you only realize after the fact that you are talking about a single idea on many pages, so you have to make changes to several pages all at once, which is annoying to do and annoying to read. As implemented, they are also redundant with the CategoriesAndTopics, which should be fixed. They feel like you need to have solved the problem before you figured out you had a problem. This doesn't mean they are useless, just that they aren't useful for simplifying RecentChanges, which means they are simply the CategoriesAndTopics in new (less powerful) clothes. -- SunirShah
So far, I like them. And I don't think having to cluster together pages "after the fact" is that bad. Then again, I haven't been around much since their heavy usage started, so I don't have much experience with them yet. I agree that they are redundant with CategoriesAndTopics, though. I would prefer a full-out CategoryFilteredRecentChanges. -- BayleShanks
I think instead of hiding the changes, one should only list the Categories as I did on CategoryFilteredRecentChanges. StevenBlack is smart. But that doesn't solve the SpaghettiWiki problem. -- SunirShah
I rather like it. Several of the clusters are ones I don't want to follow. CW's RecentChanges would be chaos without them. Adding inlining could be a good step, especially if it still listed the cluster a la CategoryFilteredRecentChanges, and/or coloured things. I don't think categories equate with interest. Hence, it's very useful to keep the systems separate. Categories are for finding information in the WikiNow. Clusters are for keeping ForestFires amenable to refactoring. They help people keep up with fires at their own pace, not the (much faster) pace of RecentChanges. -- ChrisPurcell
If clusters are only for today, clusters leave detritus behind in the WikiNow instead of on RecentChanges. The exact same detritus one would use with topics (not categories), which are forever. It is always wrong to conflate today with the now. The CommunityWiki:ExperimentalTechnology cluster is a category. But to use the now canonical example, TopicCanonicalization would be a topic. We want both CategoryFilteredRecentChanges and topic-clustered RecentChanges. I never understood how Stan differentiated topics from categories until today! cf. CategoriesAndTopics for more. -- SunirShah
Do you want topic-clustered RecentChanges the way this page suggests? -- ChrisPurcell
Perhaps DigestedChanges. -- SunirShah
Offshoot of PageClusters resulting from this discussion can be found at EditCategories.
One thing PageClusters do that closely-linked wikis don't do is work with MeatballCopyright?. -- NathanielThurston