Wikipedia talk:Delayed revisions

Previous discussion: Wikipedia talk:Flagged revisions#An alternative to flagged revisions: delayed editing reconsidered

Wikipedia is not a democracy by indicating support or opposition here we can get a better idea whether the proposal has the support of the community in general

Timing

Instinctively I'd actually go with a number more like 15 minutes, since most reverts appear to be quite quick. But this is probably something that could benefit from actual data about revert timing. Dragons flight (talk) 20:46, 29 January 2009 (UTC)

I guess it kind of depends. I just wanted to avoid anybody suggesting something more like 18 hours. I've seen vandalism on little watched pages hang for hours before getting reverted. — Blue-Haired Lawyer 21:06, 29 January 2009 (UTC)

After thinking about it so a while I'd stick with two hours. We may delete most obvious vandalism with seconds if not minutes, some of the less obvious stuff is harder to catch. Two hours means that more sophisticate vandalism on less watched pages would be found and reverted before being published. — Blue-Haired Lawyer 18:16, 31 January 2009 (UTC)

This...is bad

One point about Flagged Revisions (that a lot of people seem to miss) is that even if the 'public' version doesn't change when someone edits, it's still considered an edit in the eyes of the software -- there's no 'accidental reverting' or whatnot. Any new edits will be to the new page with the unflagged edit. With this proposal that isn't so, and it's far far more "anti-wiki" than FRs. ♫ Melodia Chaconne ♫ (talk) 21:54, 29 January 2009 (UTC)

I think you are misunderstanding. The intent, as I understood it, was to operate under exactly the same logic and technical process as FR, but that revisions would automatically become flagged (and hence "public") if they haven't been reverted (or otherwise changed) after a fixed time delay. The process for editing would stay the same as FR. Dragons flight (talk) 22:17, 29 January 2009 (UTC)

Per Dragon. Were my proposal to become reality a history page would look something like this:

• (cur) (prev) 23:32, 29 January 2009 86.45.67.96 (Talk | contribs) (0 bytes) (→BLANKED THE PAGE) (Edit pending: 23:47, 29 January 2009) (undo)
• (cur) (prev) 23:17, 29 January 2009 Dragons flight (Talk | contribs) (1,858 bytes) (→This...is bad: reply) (Edit pending: 23:32, 29 January 2009) (undo)
• (cur) (prev) 22:54, 29 January 2009 Melodia (Talk | contribs) (1,405 bytes) (undo)

The public at large would see the article as per Dragons flight's last edit. Registered editors would see the article as per 86.45.67.96's edit. It wouldn't be possible to edit the public version of the article with other edits were pending, unless of course you're reverting a pending version as:

• (cur) (prev) 23:45, 29 January 2009 Blue-Haired Lawyer (Talk | contribs) (1,858 bytes) (rvv) (undo)
• (cur) (prev) 23:32, 29 January 2009 86.45.67.96 (Talk | contribs) (0 bytes) (→BLANKED THE PAGE) (undo)
• (cur) (prev) 23:17, 29 January 2009 Dragons flight (Talk | contribs) (1,858 bytes) (→This...is bad: reply) (Edit pending: 23:32, 29 January 2009) (undo)
• (cur) (prev) 22:54, 29 January 2009 Melodia (Talk | contribs) (1,405 bytes) (undo)

Notice, no edits are pending as I've just edited the page and my delay is set to zero. I'm not sure if this is currently compatible with Flagged Revisions, but this is what I'm proposing. — Blue-Haired Lawyer 22:53, 29 January 2009 (UTC)

But what if an IP comes along and tries to edit the page after the blanking -- say, they see a typo (as they are still looking at the old version)? Will they be locked out, will they see the pending version (the blanked page), or will they edit the old version (essentially reverting the blanked version by default when they edit)? If the last option, that would be the problem I saw. ♫ Melodia Chaconne ♫ (talk) 23:16, 29 January 2009 (UTC)

Right I see now. Here's where the proposal would be like Flagged Revisions. An anon viewing a page with edits pending would see a "view draft" link instead of an "edit this page" link. Once clicked they see the latest version along with a "edit this page" link. Unlike Flagged Revisions, this kind of thing would happen much less often. — Blue-Haired Lawyer 14:14, 30 January 2009 (UTC)

One minor reservation

I strongly support the idea mentioned here, with the creation of pending edits that gives the opportunity to review edits before they go public. I believe this puts the burden in the right place. Those that want Wikipedia to remain vandalism-free bear the burden of doing the reviews to stop it, but it doesn't encumber everyone with the requirement of being an anti-vandalism cop.

Unfortunately, I think classifying by "trusted" and "untrusted" just pushes the problem elsewhere. It will just cause vandals to get accounts so they'll be trusted. Instead, I think the way to handle this is to leverage the timing aspect further.

I propose a tiered system for the timing. Suppose, for example, that anonymous edits have a 2 hour pending time. Then, we can choose an appropriate value less than this for non-anonymous editors, say 20 minutes.

An example with a Vandal and good-faith Editor:

1:00PM Baseline Article

1:30PM Vandal edits article, will become public at 3:30PM.

1:40PM Editor reverts vandalism (not yet public), will become public at 2:00PM.

2:00PM Reverted article becomes public. Contains no vandalism.

3:30PM Vandal article becomes public. Contains vandalism, but not visible, as it has been superseded by good-faith editor's cleanup.

My fear is that making any account have immediate "sighting" rights just encourages vandals to create sock-puppets with that level of rights. I think that can be avoided; edits should be judged by the quality of the edit, not by the position (trusted or not) of the editor--that just shifts the problem.

70.251.32.227 (talk) 19:04, 6 February 2009 (UTC)

There's two points here. Firstly my assumption over "trusted users" would be that the process of becoming one would be semi-automatic. Editors who fitted a certain number of criteria, including edits and time registered, would be automatically nominated and approved by an admin if they had a clean sheet (they hadn't engaged in vandalism). Secondly I'm not sure if I understand the last step of your example, particularly "Vandal article becomes public. Contains vandalism, but not public," seems to contradict itself. In anycase, once an editor reverted an edit that edit would never become public. — Blue-Haired Lawyer 21:15, 6 February 2009 (UTC)

I'm not interested in any particular "trusted user" system. I don't think it's necessary to trust anybody. That's the way Wikipedia has worked since its start. That's the way science works. No user is inherently trusted, regardless of what they do.

I have apprehensions that a review system is being turned into a trust system by moving power to individuals. That's not the way science works. For example, we don't believe/trust everything Albert Einstein claimed because he's a notable scientist. It's a good thing; he hasn't been right about everything, and his peers have shown that over time. That trust would have been misplaced. In science, the trust is an emergent characteristic of a system that relies of review by peers. I think Wikipedia would be wise to follow suit.

As for the vandalism becoming public, it does, but it isn't visible by default; it's an old revision because it was initiated earlier. I've cleaned that up a little. Make sense now? 70.251.32.227 (talk) 23:49, 6 February 2009 (UTC)

Delayed purge of the server-side cashe

I support this suggestion. I have suggested a similar solution that occasionally already works today. Sometimes it happens that the purge of the Wikipedia article to the server-side cashes is delayed. I have noticed this delay several time in the Swedish version of Wikipedia. This accidental delay has the advantage that it helps us revert vandalism before it becomes visible to anonymous users. I suggest that the purge always should be delayed, for example 2 hours after an edit.

Let my explain it from user point of view. Delayed purge would have the following effect:

1. One person edits the article, for example at 8 o'clock - anonymously or logged in. The change will not be visible immediately to anonymous users that have not edited an article recently. It will only be visible to users that have logged in, and to the editor himself, since a cookie is stored locally on his computer. These users will not see the cashed version, but the latest version.
2. The change will be visible to all users 2 hours after the first edit, i.e. at 10 o'clock. This is when the server-side cashe purge takes place, i.e. the article is "pushed" from the source web server to the server park.
3. If any user clicks at the "edit" button within the delay time, he will see the newest version.
4. If someone saves a version within the delay time, for example at 9 o'clock, this last version will be visible when the server side cashe is purged next time, i.e. at 10 o'clock. A new purge is carried out 2 hours after the second edit, i.e. at 11 o'clock, but that purge won't have any effect the article has not be revised after the last purge at 10 o'clock.

Has my suggestion been discussed somewhere else? I suggested it on the Swedish wikipedia in January 2008.

The suggestion of “delayed purge” can be improved further, if trustable users were "flagged" automatically, and if purge would take place immediately after their edit. In that case very few edits would be affected, so it would be okay to increase the purge even longer, for example to 24 hours. If there are several classes of user trustability, the delay might be different for different users. I suppose this ends up in essentially the same thing as your suggestion?

Too my understanding, both your and my suggestion have the following advantages over flagged revisions:

1. There is no risk that a revision by a non-registered user would be delayed a very long time, for example several days, if no trustable user is interested in reviewing it. Thus the suggestion would not reduce the growth of Wikipedia.
2. Non-registered users might not notice the delay, unless they check on another computer. So we would still recruit new users - they are encouraged to carry out changes.
3. Especially in small language versions of Wikipedia, where quantitative growth is just as important as quality improvement, delayed revisions is more interesting than flagged revisions, since flagged revisions might suffer from reduced number newly recruited users, and might stop the development of non-popular articles.
4. The delay time would become a recommended deadline for vandalism detection, but not a cogent reviewing mechanism that might stop Wikipedia from growth. In the normal case all revisions should be checked within the delay time.
5. Since registered trustable and experienced users are rewarded by lower delay time, people would be encouraged to be serious in all their edits, and they would be encouraged to register.
6. Wikipedia with flagged revisions is to my understanding no longer a wiki, since all articles have to be reviewed. Delayed revisions still fulfils the definition of a wiki.
7. Flagged revisions might result in the development of competing wikis that wuld be more successful, since these would grow faster. Delayed revisions would not have that effect.

Mange01 (talk) 17:25, 20 May 2009 (UTC)

Still an active proposal?

Just trying to clean up Category:Wikipedia proposals so wondering if this is still an active proposal or if it can be tagged otherwise? Hiding T 09:49, 25 August 2009 (UTC)