Last modified: 2011-03-13 18:06:38 UTC
Vandalism is currently encouraged by the wikipedia- vandalisations go 'live' immediately and the vandals get immediate positive feedback, encouraging their behaviour. The proposal is for edits by anonymous editors and new editors to be delayed from being the current generally displayed version for a period of time; for the sake of argument, for 1 day after the article has ceased being edited. Experienced editors would get their edits shown immediately as now. This mechanism would give the experienced users a chance to see the change and remove inappropriate edits; via the existing watchlist mechanism. It also discourages the vandals, and permits the first time editors to tidy up their own edits (i.e. "can I really edit this??" edits). The implementation of the idea would require having a list of recently edited pages that have been edited by 'newbies' and rendering them differently. Since this only applies to pages that have been edited within the period of time, the list would be reasonably short and is unlikely to impact performance of the wiki significantly. Differences from similar ideas: - semiprotection forbids new users from editing entirely; this idea allows it, but in a controlled way - unlike semiprotection this idea scales to the entire wikipedia, and minimises the amount of work the admins would need to do. - voting is much more complex way to do similar things, but in a wiki voting has many pathologies; cabals can form and the concept of quorate is not well defined; in addition, requiring voting can stop articles going live entirely if nobody ever votes etc. etc.
This would rapidly break the article histories if we were to implement them. What happens if Joe Anon edits revision A of an article, and saves revision B. Revision B isn't visible right away however. Meanwhile, Joe User edits revision A and saves what will be revision C. At this point, we have an edit conflict which we can't easily resolve. After a period of time, if I follow your suggestion, revision B would become the current one; out of sequence with the rest. There are too many niggles we'd have to work out.
Sorry if I wasn't clear. The version history and editing would work *exactly* as it does now. Edits necessarily have to work with the absolute latest version (even if that wasn't the displayed version); and the version list would show all versions, including newbie edits, all exactly as now. Only the 'current' version of the article that is served if you go to the article would hide anything. In your example 'Joe User' (I prefer 'Joe Editor') would get an edit conflict, *exactly* as now. The idea is not that of trying to hide Joe Anon's edits from editors- only from the *users* of the wikipedia.
If you meant that Joe User hits edit ''after'' Joe Anon hits 'save page', then he would be editing Joe Anon's version. That's the way it works in the wikipedia now- you edit the latest version, even if that isn't the version you are viewing (say, because somebody has submitted an edit since you started viewing.)
Hmm. That makes it sound a little more...I'm not sure what the word is; feasible/plausible. Wouldn't this be more or less superceded by the various bits of reviewing functionality coming into play soon?
Which? The only ones I am aware of would complement it nicely.
This is probably a dupe as it's been discussed since 2002, but I can't turn up a prior for it in bugzilla at the moment. Mark as dupe if you find it. This will be implemented with upcoming version-display work.
The only one I've found is 568, but 568 seems unworkable because it doesn't have the timeout idea where things get automatically published after 24 hours.
Suggestion: "stabler version" button to display relatively vandalism-free version of page: Have one more button at the top of an article page, called "stabler version". When a user clicks it, they would see a recent version of the page (usually not the most recent version), chosen by an algorithm designed to try to lower the probability of seeing vandalism. The algorithm would try to find the most recent version which seems to have been implicitly approved of by at least 3 editors and not disapproved of by any. (In the following, any consecutive series of edits by the same editor is treated as a single edit.) A simple algorithm would work like this: each edit is classified as being a revert or not. (In the simplest implementation, it's classified as a revert only if it is identical to the second-last version before it. More advanced algorithms could be developed.) A revert, of course, indicates disapproval of the version being reverted from and approval of the version reverted to. An edit which is not a revert is assumed to implicitly approve of the preceding edit. (The logic here is that if someone edits something in one paragraph, and then someone else edits something in a different paragraph, the second one is implying that the first one was not vandalism.) If the algorithm can't find, with a reasonable amount of effort, e.g. analysing the last 10 edits, a most recent version which was implicitly approved of by at least 3 editors and disapproved of by none (first try: 3 approving editors), then it tries to find the most recent version implicitly approved of by at least 2 editors and disapproved of by none (second try: 2 approving editors). If that also fails, then it simply returns the most recent version. (third try: 1 approving editor.) (Note that vandalism is usually not a revert, therefore vandalism is taken by the algorithm to implicitly approve of the preceding version, so in such a case the preceding version seems to be approved of by 2 editors, including the vandal, so the algorithm will not fail its second try and the most recent (vandalised) version will not be returned as the "stabler version". Also, after vandalism, usually the next edit is a revert, so the vandalised version will usually not be returned later on, either.) I believe that a simple implementation of this algorithm will display vandalism-free versions of the vast majority of vandalised pages given the current rates of vandalism and anti-vandalism vigilence. Edit history issues: Perhaps by default the most recent version is displayed. Any user can view the stabler version by clicking on the tab. If they click on edit while viewing the stabler version, they will see a warning that they are editing an older version of the article, and everything will proceed the way edits to older versions happen now. Unlike the time-based anti-vandalism feature suggested in the original bug report, this "stabler version tab" feature would allow any reader to see the most current version if they choose to. For pages edited more rarely, the most recent version might contain a lot more information, and the reader would be able to access it. Variations: the default could be to see the stabler version, with the most current version available with a "most recent version" tab. Or, users could choose the default in their skin.
Created attachment 4436 [details] time outs shut downs stack walk error ,stops computer,watchdog shuts computer down,
The content of attachment 4436 [details] has been deleted by Brion Vibber <brion@wikimedia.org> who provided the following reason: spam? The token used to delete this attachment was generated at 2007-12-18 01:15:42 UTC.
*** Bug 11770 has been marked as a duplicate of this bug. ***
Catherine, that is a whole different idea, being working on as ArticleTrust. The plan is to make ArticleTrust and FlaggedRevs compatible so that the newest "likely unvandalized" version can show by default if there is no "sighted" (manually done) version.
Pretty much done by ArticleTrust extension.
Feature does not appear to have been implemented in any recognizable form on English wikipedia, so reopening.
(In reply to comment #14) > Feature does not appear to have been implemented in any recognizable form on > English wikipedia, so reopening. > The software exists - English Wikipedia needs to gather consensus to enable it, then make a shell request in Bugzilla.
I tried searching in several places and was unable to confirm this has been completed. Unless you give me a usable reference to the documentation of the feature so I can evaluate the claim that it has been satisfactorily fixed, as the originator I am forced to reopen it as not fixed.
Per comment #15: The software exists - English Wikipedia needs to gather consensus to enable it, then make a shell request in Bugzilla. This does not belong here yet, please go to the Village Pump on wikipedia and when you gain a consensus that it should be implemented, than make a request here.
If it exists you can tell me the name of the feature or other details on it so we can check that it implements the feature as requested (or near enough), and then I can actually put a shell request in on all appropriate wikis, and then *I* will close this. Right now I can't do any of that, and I'm not convinced you have the slightest clue whether this feature has been implemented, so for all purposes this is not fixed.
[[mw:Extension:FlaggedRevs]]
(In reply to comment #19) > [[mw:Extension:FlaggedRevs]] > That is incorrect. Said extension does not include a feature to auto-review or mark things "live" just due to time passage.
I understand that the FlaggedRevs extension does however permit listing of the versions that have remained unsighted, so it looks like the feature could be implemented with a bot that checks this list and sights them as needed. I do have some concerns about performance though, but we could reopen the feature request if the performance turned out to be too poor, and use it only on tagged articles. The usability would be higher with this scheme than with conventional FlaggedRevs. However, it also seems from data from the German trial that no reduction in vandalism was observed from FlaggedRevs, so the theory that this feature is based on may be based on flawed analysis of vandalism psychology.
(In reply to comment #21) > However, it also seems from data from the German trial that no reduction in > vandalism was observed from FlaggedRevs I'd be interested to read the full study, if you have the link handy. Or if you remember somewhat where you read it.
