ExperimentalTechnology
Lifetime on a Wiki comes in a spectrum. At one end is the WikiNow, things that last until people change them. At the other end is ephemeral one-shot stuff, meta-data, there for the current community, not posterity. In the middle is an emerging idea: unstable meta-data, that lasts a fixed time, unless someone resets the timer with a page edit. (See also DelayAction.)
Some examples:
- UnstableMetaData + PageClusters: TemporaryPageCluster. Keep a page in a cluster for, say, a month after the last edit, then silently de-cluster it, i.e. remove the cluster meta-data.
- UnstableMetaData + edit summaries: edit digests. Not quite the same as current summaries, this means keeping the summary field across edits, letting each editor modify it as they wish, until the page remains dormant for some time. The summaries would be less like a ThreadMode and more like a digest. Old digests would be lost along with the edit history
- UnstableMetaData + EditCopy: StableCopy. Keep the same backup until the page remains unaltered for more than a day, then discard it. No more need for minor edits to correct typos, as the mistake will not be kept. Equally, vandalism to stable pages can be reverted without loss. Heavily-contended pages will become increasingly vulnerable to anger, perhaps forcing both sides to calm down. Also used in LayeredWikiInterface.
- UnstableMetaData + full version history: keep every backup until a page becomes stable, then discard them all. Balances auditing with ForgiveAndForget.
- UnstableMetaData + page database: SpaghettiWiki, or DeletedPage. Turns an entire page (or wiki) into UnstableMetaData, no longer safe in the WikiNow. This has motivated BrainstormPage?, for meta-pages.
- A modified version of RecentChanges (described in brief on MeatBall:DigestedChanges) solely for combating vandalism and welcoming newcomers, rather than the catch-all RC we have today. Modifications are listed by user, sorted with newbies first, and kept no more than a day or so, with no summary nor choice to hide the change as a MinorEdit.
Such information is no longer a part of the WikiNow, and solely for the benefit of the active community, but it is not totally transient, supporting a less active user than a RecentChangesJunkie (fully transient data) or a newcomer (the WikiNow). The question of how long is a good unstable period should be answered on a case-by-case basis.
Any more ideas for where this could be applied?
These are very interesting ideas. I feel that
DatePages such as
2004-09-30 seem related. Rather than have old stuff vanish after some programmer-determined time (1 day, 1 week, whatever), perhaps it would be interesting to embed a "shred date" in the title like a
DatePage, so users could select exactly how long the page they just created would last (some users would pick a date just a few days in the future, others might pick a year or so in the future).