![[Home]](http://meatballwiki.org/meatball.gif)
PeerGroups
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesRecentChanges focusses PeerReview on a wiki. However, CommunityMayNotScale: as the output of the community exceeds the ability of individual members to review, the system breaks down. Within the community, however, there will almost surely be groupings of authors interested in specific areas.
Therefore, allow the community to partition RecentChanges down by, and into, separate peer groups: clusters of pages with a common set of PeerReviewers and a common RecentChanges listing. Superficially, these will be topic-clustered, but must be based on activity to ensure a sensible partition of the commons.
Individual PeerGroups should be allowed their own standards and rules, both written and unwritten, and respected by other PeerGroups. Groups should also provide some sort of MissionStatement to provide focus; this may be a subset of the original statement of the old community, or it may fall partly (or wholly) outside it.
PeerGroups allow the establishment of an OffTopic corral, letting a community explore and develop areas of mutual interest outside the MissionStatement without diluting the focus of the main RecentChanges. This idea is also explored on SpaghettiWiki.
But, break the community into PeerGroups too eagerly and viewpoints will be lost, to the detriment of pages and people. Policing the site's content will become harder for any one individual. ConflictResolution may be prevented by over-eager forking. PeerGroups should therefore be formed only when policing is already unmanageable, or conflicts are irresolvable. Providing the technology invites people to use it over-eagerly. On the other hand, wait too long before splitting the community, and it may be impossible to divide up the pages without acrimony and EditWars.
A NameSpace may allow EditWars on individual pages between two PeerGroups to be resolved by text forking, invaluable for irreconcilable conflicts over things like copyright. However, the essential problems that arise around TheTippingPoint may be too stressful for the PeerGroups technology to resolve. Forcing a hostile faction to actually leave the wiki (hence clearly marking who retains the rights to the site's contents) may be more appropriate and ultimately less damaging.
A site with PeerGroups also risks becoming a WikiFarm for every random Joe who wants to write about his cat. A clear MissionStatement for the whole wiki may help prevent random isolated communities from forming inappropriately.
Sociology
A motivating example of a PeerGroup on Meatball is the French language translation project: a group of users maintaining a separate, but associated, community. This example allows constructive decisions about the technical design of the feature to be made. For instance, would such a community would probably want a different base URL, to make InterWiki links to just the French project easier, or would it want to share the same flat URL namespace, to make InterWiki links to the overarching Meatball project easier? Would the best solution be a flat root URL namespace, which simply redirects to the correct page where that is unambiguous, and presents the user with a choice (or even both pages) otherwise?
However, it is also important to take a step back and ask whether the translation project would benefit from its own distinct peer group yet. The community is currently a strict subset of the MeatBall folk, and benefits from the PeerReview of the entire community, if only as a bulwark against WikiSpam. Using a PeerGroup would likely only be of great assistance if the user interface duplicated the current EditCategories-based system, i.e. showing French changes on RecentChanges as an easily-configured option. This raises the question of whether such a move is necessary, or appropriate.
In the long run, though, if the French MeatBall community takes off and gains a life of its own, as we hope, turning it into a PeerGroup would be a more sensible decision. This can only be done if the engine already supports such a move.
Technology
A PeerGroup is a property of a page. While this could be displayed and set overtly in the text, or summary text, of the page — as proposed by PageClusters and TextCategories, respectively — it would be better to manage grouping with a separate tool. This makes a PricklyHedge against needless splitting of the community. It also allows implicit use of a LatticeSpace, which if properly implemented provides NearLinking, SisterSite and InterMap functionality. Providing this implicitly, rather than explicitly, is important from a usability perspective.
Peer group formation — and the movement of pages into a group — should be visible on RecentChanges, or malicious users can silently damage the site. Indeed, as PeerGroups are so powerful in their community-splitting potential, it may be best to DelayAction on their formation until the entire community is agreed; any split that is so full of dissent that it cannot achieve consensus will probably overwhelm the PeerGroup technology anyway. Which RecentChanges should display new group formation is a good question. If only some PeerGroup RecentChanges display the creation of a group, then migration of pages from other groups should be prohibited.
Visual differences will help establish separate PeerGroups. Allowing for user-supplied logos and style sheets gives a cheap way to achieve this; site-altering templates would give even more flexibility.
The engine should provide a virtual directory for each PeerGroup. The basic mechanisms of a LatticeSpace are, again, best for this: a root directory provides a simple redirect to the correct PeerGroup when the name is unique, or a list of choices when ambiguity arises. It may prove fruitful to allow some pages, such as common HowTo texts, to be visible to several PeerGroups, and a LatticeSpace also allows this to occur transparently. Alternatively, such pages could be simply duplicated.
PeerGroups differ from EditCategories and TextCategories in that they are designed to split the community of peers, not provide attention filtering. They also differ from CategoriesAndTopics in that they split the corpus based on the state of the community rather than the contents of the pages. PeerGroups are similar to PersonalCategories in that they are based on hidden metadata tags to pages. The main technology differences thus derive from the intended use.
A few other use cases could be chosen to motivate design decisions, probably resulting in different design choices. These could potentially be provided as well as the design above. For instance, using PeerGroups to implement WikiLogs? and SubscribedChanges would not require separate virtual directories. PeerGroups could, with a willing community, form a ViewPoint system; this would likely require a Subversion-like ability to tag revisions. PeerGroups could also be be combined with HardSecurity to limit access to certain pages, requiring the user to log in to access pages tagged under specific groups. The UserInterface can promote these alternate uses, for example by adding a "subscribe to this page" check-box to edit forms for logged-in users.
I wrote this about half a year ago, and never posted it. It needs work.
The basic idea (as with the move from EditClusters to EditCategories) is to rewrite PageClusters for a specific use-case, and decide exactly what that changes about the basic technology. -- ChrisPurcell