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
See also: EditCopy, [FusionWiki], WikiPedia:Wikipedia:FlaggedRevs.
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.)
See also: CommunityOverContent.
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?
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
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