Therefore, create a page where the contents of the file are stored. Anyone may edit this page. After a certain timeout period, if no one edits the page in the interim, the contents of the page are accepted and are saved to the file the page represents. But, anyone can veto the change just by editing the page. This will dissuade harmful server-side attacks that would otherwise be trivial if the file was accepted automatically. Here we benefit from all the SoftSecurity built into the rest of the site, such as PeerReview. This follows the same principle of DelayAction as KeptPages, and meatball's PageDeletion system.
This addresses both forces. We need to allow the community to administrate itself instead of putting control in the hands of AbsentLeaders or GodKings. Think of the frustration that the community would have for slow to respond proprietors. We also need to protect the site proprietors and site users from potential liabilities, and the stress of a site proprietor from having to be around to maintain the site at all times.
For UseModWiki folk, see UseMod:WikiPatches/FileReplacement.
But, avoid the VanityFear of always thinking that you necessarily need the extra level of protection given by a delay, especially for a ReversibleChange. SecurityByObscurity may be sufficient.
For content other than plain text, a FileUpload mechanism (possibly with a delay or other checks) is one way forward. Another is to create a java applet (or similar) to allow users to edit the file directly in their web browser.
On MeatballWiki, the InterMapTxt file is handled that way (see also PublicallyEditableInterMap, InterMapPublic).
A wildly empowering possibility is a CommunityProgrammableWiki - putting the script that runs the site in the hands of the community. Think NomicGame?, think lawmaking.
StableCopy and StableHistory? apply the FileReplacement model to (potentially) every single page.
While pondering how to work FileReplacement into the UseMod:MagicContent stuff I'm doing, it struck me that there is a much easier way to do this than having the script write to any old file. Let's take the Intermap as an example. Instead of reading from the intermap.txt file, have a PublicallyEditableInterMap page, and the script reads from the stored wikitext. Now that suggestion was rejected, for the very good reason that should someone vandalise the page, it breaks links across the site until the page is restored. BUT here's where the clever bit comes. The wiki script doesn't read the current version of the PublicallyEditableInterMap. Instead, it uses the following algorithm:
I'll ponder making a general implementation of this. -- TarQuin
FileReplacement doesn't work fast enough in my opinion--it has been almost non-functional for the "intermap" file. (Changes to the intermap file using FileReplacement have often taken more than a month to be effective because of multiple edits.) --CliffordAdams
Delaying deployment due to further development is not ideal. Perhaps the page could be split into a development version and a stable subpage. Then you encourage people to edit the development version, and update the stable version only once per replacement period. Updating the stable version shortly before the replacement period comes up, and thereby delaying deployment for another period, would be frowned on. Hence, deployment would only be delayed by people who disagree with the new version, not by people who want to improve it. -- TimStarling
Another thing could be positive feedback. A log of unique users or IPs that accessed the page could be kept. Any named user could reduced the time by N hours, any IP by M hours up to a minimum of X days. -- HelmutLeitner
Here's another option: by default, every version goes live after ten days. So if I make version 1 on day 1, version 2 on day 2, etc, then on day 11 version 1 is released, on day 12 version 2 is released, and so forth. However, any user may go through the history and mark old versions "not for release" (via some UI change). Thus, vandalism would need to be treated by reverting the page and marking the reverted version not for release. This system preserves "veto semantics" of the existing system. However, in continuous incremental development mode, one can just edit freely without having to worry about the replacement cycle. --MartinHarper
tdays, then it goes live, no matter how many times the actual page was edited in the meantime; equally, a removed entry that is not reinstated at all over
tdays will be removed from the actual file. Idiot spammers who replace the entire page can be discarded by only taking into account changes that leave both the #ReplaceFile ... and the <pre>...</pre> in place, and well-intentioned newbies will not accidentally annoy everyone else. -- ChrisPurcell