Wikipedia talk:Timed article change stabilisation mechanism

From Wikipedia, the free encyclopedia

Contents

[edit] Other Similar mechanisms

An m:Article validation feature is being actively worked on and will apparently be available in trial form in the not too distant future. I suspect similar ideas (like yours) will not be acted on until after this trial. -- Rick Block (talk) 04:40, 17 December 2005 (UTC)
I question the need for validation of articles. I claim that rejection of bad article revisions is far more important and normally does not require experts. The mechanisms proposed are a superset of what I propose, and the other features seem difficult to implement and at best of debateable value. A more general attempt at a solution is often not better since it is harder to use and harder to implement. WolfKeeper 05:02, 17 December 2005 (UTC)

[edit] Review of edits in general

I think requiring even the edits of mature editors to be reviewed is a good idea. We may not be vandals, but we still make mistakes. Probably the simplest scheme imaginable is that no new version would become visible until at least k other editors had approved it, with a user preference to view either the newest or most recent approved version. Deco 06:20, 17 December 2005 (UTC)
The wikipedia has done pretty well so far, without such mechanisms. It would be premature to add such mechanisms, my contention is that there may be better ways to do similar things without heavyweight voting. I also disagree with the political aspects such voting can introduce, it can introduce horse trading on articles and such like. Also groups of users can conspire to push through edits arbitrarily anyway. But that isn't at all the point of my proposal anyway. It is only an antivandalism mechanism, not a validation mechanism.WolfKeeper 06:33, 17 December 2005 (UTC)

[edit] values of X and Y

200 edits would be a very high bar. I don't think I would have made it to 200 knowing that none of my edits were going to be public for a day. 10 edits would be plenty. But yeah, there are other proposals that go into a bit more detail than this. Stevage 03:08, 18 December 2005 (UTC)
10 is much too small. Any vandal can do 10 edits typing with their nose. 50-200 should be workable. WolfKeeper 03:21, 18 December 2005 (UTC)
Any determined vandal can. But it would block the majority of vandals, including the "does this really work?" and "Johnny is gay" types. Nothing can stop a truly determined vandal.
See m:GAY. -Mysekurity(have you seen this?) 01:25, 21 December 2005 (UTC)
I think 10 is too small; IMO there are too many vandals that are more determined than that. But it's irrelevant really, such a number is extremely easy to change up or down if the scheme has been implemented. My point is not that 24 hours and 50 or 100 edits are critical to the scheme working; my point is that the general scheme is lightweight from the users point of view whilst giving good protection to the wikipedia against vandalism.WolfKeeper 11:48, 19 December 2005 (UTC)
Any fixed number is bad. After a user's first ten edits, each edit should have a 1% chance of converting the user to a "mature user". --Carnildo 00:58, 21 December 2005 (UTC)
An interesting suggestion, but 1% would be a fixed number too; and would be bad in other ways. For example I calculate that 1 user in 20948 still wouldn't be classed as mature after a thousand edits with such a scheme. That seems even more arbitrary to me. Why introduce chance into this? The wikipedia isn't actually a game.WolfKeeper 01:33, 21 December 2005 (UTC)

Part of the possible advantage of Y=24 is that new users would come back in a day to see their edits... and decide to edit some more. It's a virtuous circle; by the time they hit 50 edits, they need their daily editing fix no matter what.--ragesoss 05:43, 16 May 2006 (UTC)

[edit] developer

have you talked to developers to see if this is feasible? --kizzle 03:25, 21 December 2005 (UTC)

From a programming perspective, this idea seems very feasible. WilliamKF
The devs indicated in the WP:SEMI discussion that edit counting is not currently feasible from a computational expense point of view. -Splashtalk 17:54, 21 December 2005 (UTC)
I find it difficult to believe. There's only 700,000 editors. You only need one byte per user as a count for this. You could keep that in an array in RAM and checkpoint it occasionally as a flat file; it would't matter that much if you were a few off for this. Initialising the counts would be time consuming, but you only have to do it once.WolfKeeper 03:27, 22 December 2005 (UTC)

[edit] Support and voting idea

I support this idea. I imagine extending it with replacing the metric of how many edits an editor has made with how old their edit is with a rating system. As you edit the article, you rate recent edits. Based upon how your edits and number of edits are rated by others, your rating would count more or less. Viewers would see the last edit which exceeds some threshold. Editors would always see the latest and by editing they would be condoning prior edits that they leave behind. WilliamKF

I support this idea. I like very much that it seems so easy to adjust that a number of suggestions have already been made. That suggests that it has the flexibility to cope with unforeseen consequences and to adjust to the changing needs of Wikipedia. However, I think the original suggestion is an excellent starting point. Walter Siegmund (talk) 05:43, 21 December 2005 (UTC)

[edit] Compared to Semiprotection

How does this differ from enough from semiprotection to get any headway? Semiprotection seems pretty popular these days, I have doubts about your ability to gain "consensus", and if you ever do gain it, please let me know what it looks like.Karmafist 18:43, December 22, 2005

Semiprotection applies only to articles that are specifically selected for protection. It's a reactive approach that can only be applied to very frequently vandalised articles. Applying it to all the articles in the wiki would greatly damage the wikipedia- new editors would probably not join any more if they can't do any edits for several days after registering.WolfKeeper 20:37, 22 December 2005 (UTC)
By way of contrast, the Timed Stabilisation mechanism is a proactive approach that can be applied to all the articles in the wiki. Since vandalisation won't appear to general users, it dissuades people from vandalising in the first place, and improves the reputation of the wiki, since the users would rarely see any vandalisation; at the moment it happens as soon as the 'save page' button is pressed.WolfKeeper 20:37, 22 December 2005 (UTC)
Also, unlike semiprotection, it doesn't prevent anonymous or new editor contributions.WolfKeeper 20:37, 22 December 2005 (UTC)
It scales much better too, since it empowers the editors to keep vandalism away, rather than needing admins. Semiprotection is great for really high profile pages like GWB which get vandalised several times per day, but not so useful for less important articles. This scheme is not intended to replace Semiprotection, but work alongside it.WolfKeeper 20:48, 22 December 2005 (UTC)

[edit] Move page

Can we move this to Wikipedia:Timed article change stabilisation mechanism? This isn't UseMod, so we can have spaces in our titles. Blackcap (talk) 19:29, 23 December 2005 (UTC)

More accurately, this isn't a CamelCase website. Blackcap (talk) 19:32, 23 December 2005 (UTC)
In anycase I was bold and moved it... Thanks/wangi 19:38, 23 December 2005 (UTC)
Sure. I would have done it myself, but I figured maybe it was wanted there for some reason. Blackcap (talk) 19:39, 23 December 2005 (UTC)

[edit] Feature request

Since this is a feature request rather than a proposal, please discuss it with the developers on Bugzilla. Radiant_>|< 11:26, 26 December 2005 (UTC)

Well, I certainly agree it has feature aspects. But more important, or as important is the question of whether this policy is one that Wikipedia should follow. In other words, do we want to delay articles by a time period, or are other mechanisms/policies as or more appropriate?

I don't think that a policy as far reaching as this is just a feature.

That requires discussion and agreement. That's what this page is about.

In other words, you seem to be jumping the gun by claiming that.WolfKeeper 23:28, 26 December 2005 (UTC)

  • What I meant is that there's no point discussing it with the community if the devs will not implement it (and devs aren't generally swayed by a community vote). So please ask the devs first if this change is feasible. Radiant_>|< 10:58, 27 December 2005 (UTC)
    Optimal policy choices have little to do with what can or will be implemented. We should work out what the ideal policies are, and then have a subset of these which can actually be implemented; the rest serve as ideals to aspire to as code and other available tools (and innovative ideas of how to do more with the tools we have) develop. I'm not sure what you mean by "devs aren't generally swayed by a community vote", as devs are generally community members, and many community members become devs to implement a feature that they really want to see [and that noone else is willing to code]. +sj + 10:41, 30 January 2006 (UTC)
    • Can someone interpret the bugzilla log for those of us with less experience? [1] My reading is that Ian Woollard seems favorably disposed and Rob Church and Brion Vibber seem receptive. Does that mean it is worthwhile resuming the discussion here? I would hate to see this idea not pursued further. --Walter Siegmund (talk) 02:30, 21 January 2006 (UTC)

[edit] Use of "historical" template

Please do not use the "historical" template for pages which are only a few weeks old. The template is not for indicating one's personal opinion that a discussion should no longer be active. +sj + 10:41, 30 January 2006 (UTC)

[edit] It's great, but...

Replace "24 hours" with "10 minutes". See what happens. Increase if needed. The "many editors check their watchlists once per day" is bogus, as most pages are watched by more than one editor. If you had 100 editors watching one page, for instance, it would only need to be in quarantine for 15 minutes on average. Jumping from 0 seconds (our current situation) to 24 hours is a bit extreme, and unwarranted. Stevage 19:59, 30 August 2006 (UTC)

10 minutes is very, very probably too short. Let's say 60% of edits are fixed in say 5 minutes, and for the sake of argument that's true of every 5 minutes after that. Then about 0.4^(10/5) = ~ 0.16 i.e. 1 in 6 vandalisations would make it 10 minutes. That's too many, it's still worth it for vandals to make multiple vandalisms, the chances are good that more than one would show up on the wikipedia.
But at an hour, then it's only 1 in 60,000 vandalisations would make it to 1 hour. But that 60% only applies to average articles, you also have to worry about articles that only a very small number of users look after, and then the 24 hours is more reasonable. But I'm not saying 24 hours is the right number, the important thing is the basic mechanism, not the particular time period involved.WolfKeeper 21:50, 30 August 2006 (UTC)
Ok, put it this way - try a very small number, and see what happens. If we end up catching some vandalism before it's published, but other vandalism goes through, then what has happened - we have improved things. We can then try and improve things further. Introducing the delay at 24 hours is likely to have *many* other effects - reaction from anonymous users, reduction in contributions, etc etc. And the project may end up being scrapped due to the bad reactions, before we've seen whether it really works or not. Stevage 18:39, 5 September 2006 (UTC)

[edit] Activity?

Is this proposal still active? And how viable is it? I see there is a fairly recent discussion above, but most of the other discussion seems to date to last year...

It's viable.WolfKeeper 16:39, 25 September 2006 (UTC)

The reason I ask, is that this not only provides what seems like an effective method to combat vandalism, but the phenomenon of edit creep, as well. Most edit creep is the result of IP/anon/new users adding questionable content to well-established, accurate articles, which tends, over time, to decrease the quality of the articles as these dubious edits add up. Alternately (and this is a common problem with more technical articles, such as those falling under WikiProject Physics), what might happen is an IP might add factually dubious content, but which looks superficially plausible, and sometimes takes a great deal of familiarity with the subject to tell that it is nonsense. After that, the article might be obviously vandalised, and so the anti-vandal patrol (or bot, or whatever) comes along and reverts the vandalism, but leaves the dubious content in place: and so this content can slip by on people's watchlists, and can remain in place for months before being detected (as an example, see this thread). I think that a feature such as this would greatly improve the quality of many articles. How does something like this get enacted? Byrgenwulf 15:54, 25 September 2006 (UTC)

Basically it looks like it's Jimmy Wales' call. It came up on WIKIEN and He doesn't seem to particularly favour it at the moment, but there's an experiment going on in the German wikipedia that is very similar (although we don't know precisely what they're up to, but the accounts I've seen suggest it is this kind of thing). If that works out he'll probably pick it up. There's also the point that this article may influence the German implementation.WolfKeeper 16:39, 25 September 2006 (UTC)
Retrieved from "http://en.wikipedia.org../../../t/i/m/Wikipedia_talk%7ETimed_article_change_stabilisation_mechanism_34bc.html"