PageClusters

MeatballWiki | RecentChanges | Random Page | Indices | Categories

PageClusters are an attempt to preserve GlobalResources when CommunityMayNotScale: an easy-to-use, deliberate way to maintain the focus of a larger group of users. Ideally, they should support BarnRaising by allowing several barns to be raised at once, at different paces, with people moving from barn to barn as their time permits.

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:

Page clusters are dynamic. By changing the link to the main page, you change the cluster the page belongs to.
Every page in a cluster still belongs to the very same flat top-level namespace. The only visible effect is on RecentChanges.

The visible effects on RecentChanges of clustering a page:

Edits to pages belonging to a cluster are not visible.
Edits to pages belonging to a cluster are shown when the main page of the cluster is visited.
Edits to the main page itself are be shown as normal.

Benefits

Create a brainstorming session without harassing RecentChangesJunkies (e.g. TopicCanonicalization)
Create a sub-project, under the MeatballMission, whose workings are not of day-to-day interest to most Meatballers (e.g. the TourBus, FacetWiki), especially if the summarised findings are interesting (use the main page to post an update log)
Simulate having your own Wiki, with its own RecentChanges page, sharing a namespace with MeatBall
Allow a WikiSubcommunity to explore ideas without broadcasting them to the larger community (better than MinorEdits).
Recan a ForestFire in a looser fashion

What it cannot achieve

EnlargeSpace, except insofar as it makes using more of the flat NameSpace of MeatBall more palatable
Interweaving of clusters is not supported by the given syntax. Each page can be in at most one cluster.

Specific advantages

Here is a list of benefits page clustering has over similar ideas such as FractalWiki or ParallelWiki.

No worries about how to link to a page (c.f. FractalWiki)
Clustered pages can be worked into the rest of the site by links just as if they weren't in the cluster (c.f. FractalWiki)
Just as visible as writing "This page is under construction" (a proposed brainstorming solution-by-convention)
The author's energy works for the community, with voluntary filtering
Keeps a central change-point for each project, both relieving pressure from RecentChanges and logging edits where they properly belong
Pages that have grown beyond the project they are part of - say, if PeriPeri:ContextualLinking became prevalent outside of the FacetWiki project - a single, simple edit will confer that status without needing to copy between Wikis or anything

Conclusion

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

Alternative - Alternative Cluster Mark

Use the MetadataSyntax. This lets a page be in multiple clusters, and minimises accidental clustering. Nice if the syntax is already used for other meta-data. Provides clarity when editing a page what that strange initial link is doing. However, adds language issues for multi-lingual sites.
Provide a field on the edit page for clustering. Saves on more cruft in your wiki's pattern matching, but not on FeatureKarma.

Alternative - Cluster Clustering

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.

Extension - Inlining

Allow users to explicitly list a particular cluster's changes on their RecentChanges (to avoid needing to follow individual listings/RecentEdits?)
Ideally, use an InfiniteMonkey-style combination of URL query parameters and cookies to achieve this
List included clusters at the bottom of the RecentChanges page, with a link to turn each off, for convenience

Advantages

Regains the standard Wiki change-point, so people permanently interested in a project don't need to check an extra page or wait for a major status-update.

: The OddMuse implementation allows you to visit any page A and display the changes to all pages belonging to a cluster B. Therefore, you can have the list of recent changes to one cluster on your homepage, if you want to.

Extension - Clustering with options

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.

Extension - Exclusion

Allow users to create their own pages which list other pages they don't want to hear about, and to filter them out of RecentChanges.
Possibly add other options (exclude everything not on a list, include contents of a list, etc.) to allow a very personal RecentChanges setup.

Advantages

Handy for the chronically short of time, assuming said people have the time to set up the system.

Extension - Colour coding

Allow clusters to be colour-coded (a user preference on a per-cluster basis)

Advantages

Helps make RecentChanges less of a splat even when clusters are inlined

PageClusters as WebLogs

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.

Password Clusters

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.

If the Clustering changes extension were used, a password cluster would default to invisible until one first entered the password, at which point making it included would make sense.
Obviously, a namespace system would be desirable for this extension, because otherwise a project could abuse the namespace and nobody else could oust it (not having password privileges).
Setting up a new password cluster would be a privileged operation.
Removing a page from a passworded cluster would need to be verified (to prevent malchance), but not privileged (the password protection is enough)
One could easily make PasswordCluster a page cluster, creating a central point for all passworded-projects.
The front page of a password cluster would serve as the publically-viewable description. It could include a project log, a description, a list of participants...

This system is not advocated for a fully open Wiki like Meatball.

OddMuse Implementation

Variation used:

Cluster clustering
Main page must be visited via RecentChanges to view the cluster log, unless the main page is in the cluster

See OddMuse:Page_Clusters

In favour of cluster marks

One nice advantage of cluster marks is that we do not put irrelevant information first, e.g.

 PageCluster: CategoryIdentity

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.

Discussion

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

CategoryWikiTechnology CategoryUncommonWikiTechnology CategoryRecentChanges