StableCopy

MeatballWiki | RecentChanges | Random Page | Indices | Categories

The StableCopy of a page is the last revision that remained unchanged for a fixed period of time, such as a day, fortnight, or moon. By virtue of its stability, the StableCopy is more likely to be accurate, boring, and free of vandalism, flames, etc.

In general, the StableCopy is suitable for those merely reading a page (whether community members or part of TheAudience), whereas the current version is suitable for those currently working on a page. As a simple filtering system, choose to display only the StableCopy of each page to the casual viewer. As an enhancement to VersionHistory, only store the prior stable copies of a page. Optionally also store the unstable versions created after the last stable copy. Alternatively, store the full VersionHistory, but make the stable copies more accessible.

Giving weight to the StableCopy over other revisions gives users a simple veto over changes. In many situations, this will be ideal, but the power of veto does not scale: increased editorship will demand an alternative means of selecting "stable" (or "major") revisions. Pages must also naturally stabilise: confining a WikiLog, RecentVisitors, SandBox or any other frequently-updated artefact to a single page, for instance, will typically result in newer changes falsely vetoing older, unrelated changes.

StableCopy is an instance of AuthorizedCopy where the authorization mechanism is SilentAgreement over a fixed timespan, with all community members possessing veto power. Comparable ideas include ReviewedWiki, which relies on community members explicitly reviewing changes and moving them to the StableCopy, and ConsensusGroup (VetoTopic), which allows users to explicitly approve changes to hasten the PeerReview period.

Required by: LayeredWikiInterface, PeriPeri:StabiliserThrottle, StableView

Stabiliser Throttle

A StabiliserThrottle? blows away the current version of a page, reverting to the StableCopy, once more than x edits have occurred with none going stable. Further edits to the page are banned until it is left alone for a day.

Medium-term Wiki disruptions - flame wars - involve frequent, persistent changes to disputed pages. Any of the community who intervene negatively risk getting dragged in and maligned. The Stabiliser throttle aims to indiscriminately squash the edit war, hopefully allowing the community to stick to positive approaches to resolution.

As with StableCopy, the Stabiliser risks losing positive contributions that have not gone stable, and perpetuating vandalism if it is accidentally left to stabilise. Both can be addressed positively by CommunitySolutions.

(Text duplicated from PeriPeri:StabiliserThrottle.)

Stabiliser Throttle case study: page "xxx", late June 2005

Any reasonable setting on a stabiliser throttle would have blown away xxx by now, even with a sub-day stability period. What are the facts?

There have been 80 changes in 5 days, as of 22 June.
The page consists of a long series of passionate arguments for and against xxx, with no consensus.
There is a definite degeneration of communication.
There is no sign of TrollingTactics, just passion.
The energy is contained within a single page, not spilling into a ForestFire.

If we aim to DefendAgainstPassion, the throttle triggering would thus be correct behaviour. In this case, stabilisation could serve as a hard reminder to all participants to DefendAgainstPassion, especially if text to that effect were liberally sprayed all over the (disabled) edit form of the stabilised page.

Such a throttle risks inflaming the situation, and risks starting a ForestFire as other pages are co-opted to continue the argument (or to discuss the idiocy of using a stabiliser). However, one important participant stated that, had a throttle triggered: "I would have asked for explanations (either by email or on wiki), and if such a device would have been maintained, I would have stopped contributing to this site. So if your criterion is reducing the level of conflict to unnoticeable, such a device would have certainly been up to the task."

I'm not entirely convinced that destroying people's words is a positive or effective method to alleviate conflict. It's better to simply freeze the page rather than auto-revert. -- SunirShah

: The problem with freezing the page is simply that it allows a total spam attack on the entire site to succeed in neatly removing the ability of the average user to revert patent rubbish. The StableCopy seems the only generic choice to avoid this problem. -- ChrisPurcell

: StableCopy solves the "vandalism will ruin our reputation" and the "EditWars make the history unusable" WikiPedia whinges. --MartinHarper

Yes, and they're fighting over it (they call it Flagged Revisions) because it will only confuse people that go edit the page and realize that the copy they're editing is different from the copy they saw earlier. - NatalieBrown

: It's not quite the same technology (Flagged Revisions must be manually flagged, StableCopy is fully automatic), but the objections would apply to either -- ChrisPurcell

CategoryWikiTechnology

StableCopy

Stabiliser Throttle

Stabiliser Throttle case study: page "xxx", late June 2005

Discussion