![[Home]](http://meatballwiki.org/meatball.gif)
StableView
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesThe StableView of a site is based solely on the StableCopy of each page. This means:
- The text of each page is the last version that went stable, not the current version.
- A BrokenLink is displayed if there is no stable copy of the linked page - even if there is a current version.
- All auto-generated content must be based on stable versions. Category listings, for instance, must list pages that were in the category when last stable, including ones that have since been removed, and excluding pages that have since been added.
- The RecentChanges listing can only display stable versions of pages. (This would motivate the use of DigestedSummary.)
A StableView prevents vandalism from deterring or disappointing newcomers, who may not know how to find an unvandalised copy of a page. If a site has a StableView, external links should route through it.
StableView can be coupled with an EasySubmission to expose a friendly, less vulnerable face to newcomers, while still allowing anyone interested to see past the stable and into the fragile heart of Wiki to join the community. See LayeredWikiInterface.
Alternatively, StableView can be combined with a restricted editing policy (e.g. on a personal wiki) to allow a user to fix mistakes in a page before it goes live.
StableView makes it hard to ensure pages update simultaneously, increasing the importance of an automatic ReverseIndex in creating a topic with frequently-added new pages, and motivating explicit support for EditDependencies in the WikiEngine.
StableView on MeatballWiki
Currently our servers keep crashing as misbehaving spiders are launching a million MySQL? connections. We also want to discourage spam. One solution is to expose to Google, Inktomi, MSN, Yahoo! Slurp a static html version of the wiki. We could publish only those pages that have survived the KeptPages expiry period as static HTML, with a link back to the live version of the page (possibly through a <form>). There are major consequences to this, not the least of which is that contributors will have a harder time finding how to contribute and our PageRank will hit zero. Also, it is not yet determined if spammers will be deterred (most can't read English). What do y'all think? I only have half worked out the consequences. -- SunirShah
- We don't keep the stable version of heavily-edited pages. We only keep two weeks' worth of edits plus one. We would first need to move to the stabilization system for deciding when to discard history.
- StableCopyEmpiricalResults tells us that we can expect there to be occasions where a hundred edits are made before a page stabilizes. Fortunately, the log-normal distribution means this tail is very small. Unfortunately, it needs to be explained to editors. Also, with the recent increase in spam, this distribution has doubtless got skewed away from "short".
- A StableView of the site exposes the problem of EditDependencies, which hasn't been solved yet. It probably creates social pressure to simply "stick" with a suboptimal page just to get it into the stable view, and will doubtless generate social friction if a newbie comes along and fixes a typo on a page one day before it was going to stabilize. We would also need a way of highlighting visually what's been changed on an unstable page — and making it extremely clear to newbies that what they're seeing is a diff, and what they're editing won't be what they first saw.
- I would be against a trial of StableView on MeatballWiki. We have few real editors as it is. -- ChrisPurcell
CategoryWikiTechnology CategoryUncommonWikiTechnology