robchur wrote:

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.

ian.woollard wrote:

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.

ian.woollard wrote:

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.)

robchur wrote:

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?

ian.woollard wrote:

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.

ian.woollard wrote:

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.

an588 wrote:

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.

hensleyz wrote:

time outs shut downs

stack walk error ,stops computer,watchdog shuts computer down,

attachment bootstat.dat ignored as obsolete

The content of attachment 4436 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.

ian.woollard wrote:

Feature does not appear to have been implemented in any recognizable form on English wikipedia, so reopening.

mike.lifeguard+bugs wrote:

(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.

ian.woollard wrote:

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.

bretthillebrand wrote:

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.

ian.woollard wrote:

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.

ian.woollard wrote:

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.