Dividing the commons of a wiki up helps its users PreserveGlobalResources without creating a whole new wiki to ease the strain. Some problems, such as irreconcilable divisions in the community, are better handled by such a rigid division. Even within a tightly-knit community, however, a DividedCommons allows flux.
|DividedCommons + AllPages||Categories|
|DividedCommons + RecentChanges||PageClusters, or topics|
|DividedCommons + Page database||Some kind of namespace (see FractalWiki and FacetWiki)|
|DividedCommons + Page history||A form of VersionHistory|
The common element is the use of an arbitrary Wiki page as the pivot for the division. A page can root a category or cluster; it can root a subdirectory or facet; it can root a version. Combining with UnifiedCommons allows a directed graph just as complex as the spaghetti links of Wikis, with simple titles instead of version numbers or URIs.
Some schemes have suggested conjoining the means of dividing different commons, either conflating categories and clusters, or hiding the changes of a subdirectory from the general RecentChanges. This simplifies use of the overall system, at the cost of flexibility. It is also important not to conflate the ideas in the pattern language we use.
To Alex: I don't think the kind of VersionHistory I am dimly illuminating here is one I have found before. The keys is in the subsequent paragraph: a different page roots each revision. It's strongly reminiscent of KeptVersions, in that the root page could be the user who decided to keep the revision. However, it could also be a page covering a revision of some software, as in WikiAsSourceControlRepository. I've kept it vague because I have no clear idea how it would work. For now, it's just an interesting combination of ideas. – ChrisPurcell
Is this BranchingWiki? Adding NameSpaces and PageRenaming? would give you a ViewPoint system, I believe. This goes beyond a namespace system, because the page histories are not something they all have in common anymore; in every namespace, you'd be looking at a different branch of the history. There are common ancestors, but the histories split at some point. – AlexSchroeder
It becomes more like BranchingWiki with the relevant part of UnifiedCommons thrown in. (As it stands above, it's just a way of marking certain revisions.) However, given a namespace system where anyone can squirrel away a copy of a page into their namespace, I'm still unclear as to how it aids anything. Perhaps:
So, for example, we could create a "snapshot" archive of various parts of CommunityWiki. It wouldn't be disrupted by new discussions emerging on its pages, and it wouldn't obstruct said discussions. In a WikiAsSourceControlRepository, we could have stable versions of the code even as the unstable version progresses.
I've just figured out how this system should interact with FacetWiki's lattice-space, so am a little more comfortable with it.
Addendum: I may be talking on too little sleep, so if I'm not making sense on some points, bear with me, and I'll fix it later
By itself, this could also help limit the impact a ForestFire has on any RecentChanges system. Instead of putting the pages into a PageCluster - not valid if the ForestFire is, e.g., defacement of pages by an irate community member - you pour the offending revisions into a page, such as the defacer's HomePage, and get the benefits of a PageCluster on RecentChanges without the risk of future revisions getting caught up.
I think the point is that the category page allows you to list a subset of all pages (be it via search or built-in categories).
And, moreover, the split is rooted in a Wiki page: the category page.
Define external redirect: PageRenaming