[Home]VersionHistory

MeatballWiki | RecentChanges | Random Page | Indices | Categories
A version history records prior versions of a page, so that they may be retrieved at a later date.

1. Implementations
2. Why provide some version history?
3. Why provide full version history?
4. Why not provide full version history?
5. Pinned pages
6. Forked pages

[CategoryWikiTechnology]

1. Implementations

Many ideas have been proposed for version history schemes. They include:

Possible enhancements:

Additionally, users can always archive versions of pages that they wish to protect on their own hard disks, and copies may be archived by Google, or by the InternetArchive?. This allows for limited protection even on sites with no version history. Finally, you can create a manual history by periodically copying a page into archived old versions.

2. Why provide some version history?

Version history helps a Wiki recover from vandalism, as it is a ReversibleChange. This means users can sleep better. A full history, or KeptPages, provides essentially complete protection from vandals. EditCopy provides limited protection, but does not protect against malicious, knowledgeable attackers. A well as deliberate vandals, version history also protects against accidental "vandalism" from newcomers.

Version history reduces ReworkingProblems: history gives people confidence to make sweeping changes to a page. People are more free to remove content from the current version, because the old versions will remain available for a decent time. Programmers in particular will be aware of how much easier it is to radically modify code with the confidence of a backed-up and versioned source code repository. The same applies to other content, though this is less important if you value CommunityOverContent.

Also:

3. Why provide full version history?

A full history discourages vandals: because anyone can add rude words and have them stored for posterity, we LimitTemptation. In particular, this discourages vandals from re-adding the same piece of vandalism multiple times in an effort to prevent it ever being fully removed.

A full history is also nice for nostalgia, and for demonstrating that the wiki process works. However, you don't need a full history for this: regular snapshots would serve the same purpose. Alternatively, a ChangeLog can also provide nostalgia, even without the page contents: [1] - you can see who's been talking on a page, how active it was, and the edit summaries.

4. Why not provide full version history?

A full history encourages vandalism by preserving it for posterity. This allows "usenet performance artists" and the like to link to the vandalised version to demonstrate their superior humour and sociopathy.

A full history makes it trickier to remove copyright violations. Arguably, copyright violations in history are acceptable, because the VersionHistory is not being "published", but rather is an "editorial tool" to help users build articles. People who complain about copyright violations are typically satisfied with removing the material from the current version, caring much less about the history, so defend against CopyrightParanoia.

5. Pinned pages

Instead of keeping many pages, keep (or pin) one copy of the page. The next time someone pins a page, blow away the old pin. This way, when a page stabilizes--say after a reworking--, you can pin it and continue with discussion.

I also thought of this, and called them "accepted" pages. I may make this an option for sites that either want more editorial control (the accepted versions might be what ordinary users see), or don't want to keep older versions. One difference is that I would limit the people who can accept a page. (I don't think "accepted pages" will happen for Meatball.) -- CliffordAdams

6. Forked pages

Make a page exist in non-linear time! Allow users to fork a copy of the page which are also editable (though not necessarily forkable). Only the latest version of the main thread of the page is directly linkable. The rest can only be seen through a protacted "history of this page" view. This will allow versions to be made but corrections to be made to remove embarrassment.

My view is that a version with embarassing old mistakes should just be removed (possibly with some content copied elsewhere). In exceptional circumstances the entire page might be removed and restarted with the current content. Authors will probably have more control over their contributions and their "home pages". -- CliffordAdams

I thought this was interesting, because on EnglishWikipedia we occasionally end up with effective forks: implemented in two ways:

It'd be interesting to have explicit fork support in the software - might help to EnlargeSpace. However, I suspect this would be a case of too much coding work for too little gain.

You could solve the loss of history, and achieve a form of forking, by allowing pages to be copied and renamed. Copy DisputedArticle to DisputedArticle/temp and the history is copied. Rename a later DisputedArticle/temp as DisputedArticle and the new history is moved with it. You could even keep both versions in subpages, linking to them both from the main page, and swap in whichever one eventually "wins".

That is ViewPoint.

I wouldn't go that far. Everyone can view every fork, you cannot have different pages mapping to the same name for different people, etc. All that I am suggesting is that you be able to duplicate the history of one page on another (new) page.

If the VersionHistory is stored as a graph (or more specifically a directed acyclic graph), then a fork happens when the out-degree of a revision node is greater than one. A merge operation, to remove forks, would create a revision connected to the previous revisions. VersionHistory of a page becomes the path of all connected nodes. Whilst using graphs maybe require some more development time, they do offer some advantages

An example of the relationship between certain wiki features and the way a wiki is the availability of diff. KmWiki e.g. doesn't have diff. Obviously Denham uses it primarily as a PIM, although he invites contributions. But because of the lacking diff in combination with rather long pages it is hard to work with in the usual way. So KmWiki is of little use for communication purposes and remains more or less a PIM. -- HelmutLeitner

Yeah the DiffFeature? is something we're missing on [KayakWiki]. We seem to be getting by ok without it, but as you say, it does become difficult on long pages. -- HarryWood

I think it interesting that we think of VersionHistory as necessary for authorship credit, when a simple list of contributors would be sufficient. After all, it is pointless to try to attribute every word written in a collaborative effort.

This page does point out that a full version history is just one way of giving AuthorshipCredit, and probably not the best way either. AuthorshipCredit has much more detail, including the ContributorTagging? option you mention.

I've seen several publicly editable wiki websites which do not have a VersionHistory feature, hence no ReversibleChange. The reason in all cases, has been that someone has seen the wiki idea, and decided to try and create wiki software themselves. It's logical enough, that you would implement basic wiki editing, prior to the VersionHistory feature, but do these people not realise that a wiki really doesn't work without ReversibleChange? The only value of such software would be in a fully trusted GatedCommunity environment, but even then, people can accidentally make bad changes.

If a wiki newbie comes along and looks at one of this half-assed wiki-wannabe sites, they wouldn't have to be a genius to realise that they should not spend any time contributing content to that website, because any schmuck can com along and permanently destroy all the work. Even worse would be if they didn't realise this, and then some schmuck did destroy all their work. What bothers me is that this gives the wiki concept a bad name. Perhaps all wikis will be tarred with the same brush. -- HarryWood

It would be useful in WikiSciencePublication to be able to retain hard links to past versions of scientific articles if those scientific articles were open to being edited. A review of an article should point to the version of the article that was actually reviewed, not the current version. A good page history system could facilitate hypertext link-mediated access to old versions of articles. -- JohnSchmidt

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: