On Aug 7, 2005, at 9:47 AM, Mark Miller wrote:
The C2 wiki has also been having problems recently, from both spam flooding and an edit war (with automated scripts controlled by two parties constantly pinging between two versions of some pages). Arguably, however, the response to those problems -- to sometimes restrict access using a password for large IP ranges -- has been as detrimental to the usefulness of the wiki as the spam or the edit war itself. See WikiWikiWeb and ShortMessagesWikiWikiWeb.
Here is my suggestion for a "reviewed wiki" that would address these problems, but without making it harder to contribute to the wiki for either regular or new users.
A reviewed wiki would have two versions of each page:
There are links at the top of each page that switch between reviewed, unreviewed, and a side-by-side diff of the two. Links between pages stay in the current mode. Change bars mark paragraphs that are different between the two versions. Tools are provided to see which of the pages you are able to review have unreviewed changes (e.g. listed by time since first unreviewed change, or by the extent of changes).
(This is in addition to any historical revision control support, e.g. as already provided by the Wikimedia software: http://en.wikipedia.org/w/index.php?title=Main_Page&action=history . In that case you would have revision histories for both the reviewed and unreviewed versions, with links showing corresponding revisions.)
If you create a page, you get the authority to review it, you can delegate that authority, and you can revoke any delegations. The *default* option when creating a page (except for HomePages, see below) automatically delegates its review authority to some set of trusted reviewers for this wiki. This is so that if you lose interest in a page, it will still be reviewable (you can override this and keep exclusive review authority, but it is in your interest not to in most cases). The wiki operator(s) can also delete any page or revoke/ transfer any review authority (to delete spam that is squatting on useful page names, for instance).
On most wikis, there is a UserName mechanism that is used on various tools pages to report which user made an edit (an IP address or hostname is reported for anonymous users). This UserName is also by convention the name of the user's HomePage, if they have one. On reviewed wikis this convention should be enforced: when you create a page, there is an option to designate it as your HomePage, which also sets your UserName (and disables the default delegation of the page's review authority to trusted reviewers). This is the only way of setting your UserName -- which effectively enforces a first-come, first-served policy for UserNames on each wiki. Of course, these are pseudonyms, not True Names (any policy that prefers the use of RealNames on a given wiki [UseRealNames, Wiki:RealNamesPlease] notwithstanding).
The ability to quickly change between reviewed and unreviewed wikis means that users who just want the most up-to-date view, and don't care about whether they see spam, edit wars, personal attacks, inaccurate technical information, etc., can have what they want without undue interference. This takes into account an important lesson (IMHO) from C2: different parts of the user community have very different opinions about how much these problems matter, and some may consider measures taken to prevent or limit them as doing more harm than good. An edit war, spam flood, etc. that is only affecting a small proportion of the content of a large wiki should not lead to heavy-handed global restrictions on editing.
Note that as well as providing a reviewed version of the wiki content, an important goal is to decrease the incentive to attack the wiki in the first place. If attackers know that *by default*, most users won't see the result of their efforts, then presumably they will have less incentive for an attack. Also it is possible to use robots.txt to tell search engines to index only the reviewed wiki, which would eliminate what is apparently the main incentive to post spam.
Something like this would make wikis useful for applications where there is a particular person/group/organization that wants to be in control of the content and to enforce a level of quality or accuracy, but also be open to external contributions (this could include the official documentation and web pages for practically any open-source software project, voluntary organisation, etc.) Currently wikis are used only occasionally for this kind of application, and when they are used, they must either implement password-based access control, or rely on security-through-obscurity. Even trivial access controls can be enough to put off casual contributors, who might otherwise have turned into important long-term contributors. -- DavidHopwood?