It amazes me, but several times in the past week, I've been blindsided by page move vandals. The current restriction apparently allows moves automatically after a week?
So, for example, we see see "User:Thing that goes on feet" create a new user on 2006-06-20 07:38:17, make no contributions for over a week, and suddenly do nearly 100 moves from 2006-07-01 13:46:01 to 13:52:55.
That's right, as many as 4 moves per second!
So, I propose 2 things:
No bot or editor or administrator should be able to do more than 1 move per minute. Just reject them. That should be easy to do in software. And maybe enforcement of clearing double redirects.
No bot or editor should be able to do more than 1 edit per 20 seconds. Just queue the edit until the time has elapsed. Of course, administrators should be able to go faster, as they may be hurrying to fix a problem.
Heck, these days I often have to wait half a minute to see the response anyway. But I've noticed "edits" at a rate of 2-3 per second from "normal" editors at times, and when confronted they've claimed they aren't using a bot. Maybe not, but slow them down enough that others can notice the changes and react in human time frames.
Bug 6513
On 02/07/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
It amazes me, but several times in the past week, I've been blindsided by page move vandals. The current restriction apparently allows moves automatically after a week?
Moves are restricted to logged-in, autoconfirmed users. Right now, that means a user whose account has existed for 4 * 86400 seconds, or four days.
No bot or editor or administrator should be able to do more than 1 move per minute. Just reject them. That should be easy to do in software. And maybe enforcement of clearing double redirects.
I explained on the recent bug you filed that the ping limiter was switched off and even wrote that we'd need to rewrite it.
No bot or editor should be able to do more than 1 edit per 20 seconds. Just queue the edit until the time has elapsed. Of course, administrators should be able to go faster, as they may be hurrying to fix a problem.
Queuing edits brings problems of its own.
Rob Church
On 7/2/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
No bot or editor or administrator should be able to do more than 1 move per minute. Just reject them. That should be easy to do in software. And maybe enforcement of clearing double redirects.
No bot or editor should be able to do more than 1 edit per 20 seconds. Just queue the edit until the time has elapsed. Of course, administrators should be able to go faster, as they may be hurrying to fix a problem.
Queueing moves? Eep. Why not just reject page move requests that take place within 60 seconds of the last, with no restrictions for admins?
Heck, these days I often have to wait half a minute to see the response anyway. But I've noticed "edits" at a rate of 2-3 per second from "normal" editors at times, and when confronted they've claimed they aren't using a bot. Maybe not, but slow them down enough that others can notice the changes and react in human time frames.
It's possible to edit at 2-3 per second without using a bot, if you open multiple tabs in your browser, and press "save" almost simultaneously in them all. I've done that on a number of occasions. Also, AWB isn't a bot, but can exhibit behaviour like that.
Steve
Steve Bennett wrote:
On 7/2/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
No bot or editor or administrator should be able to do more than 1 move per minute. Just reject them. That should be easy to do in software. And maybe enforcement of clearing double redirects.
Queueing moves? Eep. Why not just reject page move requests that take place within 60 seconds of the last, with no restrictions for admins?
Sorry, but that's not what I wrote in the paragraph above, "Just reject them." I'd include the same restrictions for administrators.
There are too many administrators that may be well-meaning, but skim without understanding instructions, or don't bother to fix double redirects, or are quite simply technically incompetent.
No bot or editor should be able to do more than 1 edit per 20 seconds. Just queue the edit until the time has elapsed. Of course, administrators should be able to go faster, as they may be hurrying to fix a problem.
I'd thought queuing edits would be OK, with no restrictions for administrators. Don't have any idea how hard to implement here. In my long ago database days, it was a feature that was implementable in foxbase, so I'm sure that the fancier tools of today would be easy.
Heck, these days I often have to wait half a minute to see the response anyway. But I've noticed "edits" at a rate of 2-3 per second from "normal" editors at times, and when confronted they've claimed they aren't using a bot. Maybe not, but slow them down enough that others can notice the changes and react in human time frames.
It's possible to edit at 2-3 per second without using a bot, if you open multiple tabs in your browser, and press "save" almost simultaneously in them all. I've done that on a number of occasions. Also, AWB isn't a bot, but can exhibit behaviour like that.
It might be possible, but it's not desirable in a shared environment.
And AWB is capable of running without user interaction, so it's a bot.
"William Allen Simpson" wrote
.. And AWB is capable of running without user interaction, so it's a bot.
AWB can be used in bot mode. But then, the user must be logged in and registered at http://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/CheckPage#Bots under the section "Bots" (a fully protected page).
And AWB cannot do page moves.
--Adrian
On 7/3/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
Sorry, but that's not what I wrote in the paragraph above, "Just reject them." I'd include the same restrictions for administrators.
Why? We trust admins.
There are too many administrators that may be well-meaning, but skim without understanding instructions, or don't bother to fix double redirects, or are quite simply technically incompetent.
Sack 'em.
I'd thought queuing edits would be OK, with no restrictions for administrators. Don't have any idea how hard to implement here. In my long ago database days, it was a feature that was implementable in foxbase, so I'm sure that the fancier tools of today would be easy.
It just sounds like a lot of work for not much gain. There is absolutely no problem whatsoever with people making fast edits *except* on the rare cases of vandalism. Much better to *detect* the fast edits, alert an admin, then block them if they're a vandal. In any case 1 per 20 seconds is very slow...there are plenty of times I've edited faster than that, and waiting for the edits to be queued would get very tedious very quickly. And for what benefit?
It's possible to edit at 2-3 per second without using a bot, if you open multiple tabs in your browser, and press "save" almost simultaneously in them all. I've done that on a number of occasions. Also, AWB isn't a bot, but can exhibit behaviour like that.
It might be possible, but it's not desirable in a shared environment.
???
And AWB is capable of running without user interaction, so it's a bot.
I didn't realise that, thanks.
Steve
Steve Bennett wrote:
On 7/3/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
Sorry, but that's not what I wrote in the paragraph above, "Just reject them." I'd include the same restrictions for administrators.
Why? We trust admins.
At least on en:, administrators are primarily chosen based on activity and popularity (and often flamboyance), rather than technical competence or "trust".
The selection mechanism has been proposed for revision numerous times, with extensive polling, but it is as it is.
It would probably be better to return to the original Wales dictum, "This should be no big deal".
Then, we would only know that administrators aren't new, and have some acculturation, but not "trust" in a security sense.
There are too many administrators that may be well-meaning, but skim without understanding instructions, or don't bother to fix double redirects, or are quite simply technically incompetent.
Sack 'em.
There is not much of a viable mechanism for doing it.
Heck, there's a recent en: administrator that lied during evaluation (saying s/he was no longer involved in userbox wars), and within hours of getting the flag began deleting userboxen (sometimes with provocative edit summaries), even where the specific userbox had survived TfD and CfD evaluation by the community.
In one specific case of edit warring with fellow administrators, s/he expanded the User Christian userbox to be a page long, because they kept restoring it after s/he deleted it.
If such an egregious case cannot be removed, then there's really not much hope for merely the careless and incompetent.
On Mon, Jul 03, 2006 at 01:40:03PM -0400, William Allen Simpson wrote:
The selection mechanism has been proposed for revision numerous times, with extensive polling, but it is as it is.
It would probably be better to return to the original Wales dictum, "This should be no big deal".
Then, we would only know that administrators aren't new, and have some acculturation, but not "trust" in a security sense.
This *is* an important point, folks: Schneier just ran a column a month or so ago about "presumed credentials": assuming the UPS guy *is*, just because he's wearing a brown outfit with a logo on it.
The piece was about Improv Everywhere's 'Mission: Best Buy', and it's at:
http://www.schneier.com/blog/archives/2006/05/people_trusting.html
The lessons Bruce draws from it are probably good things to ponder over on the topic of 'what's an administrator?"
Cheers, -- jra
Restrcitions like this may have unwanted affects on large legit proxy/ ISP proxy servers.
xaosflux
----- Original Message ----- From: "William Allen Simpson" william.allen.simpson@gmail.com To: "Wikimedia developers" wikitech-l@wikimedia.org Sent: Sunday, July 02, 2006 3:24 PM Subject: [Wikitech-l] page move vandalism restrictions not working
It amazes me, but several times in the past week, I've been blindsided by page move vandals. The current restriction apparently allows moves automatically after a week?
So, for example, we see see "User:Thing that goes on feet" create a new user on 2006-06-20 07:38:17, make no contributions for over a week, and suddenly do nearly 100 moves from 2006-07-01 13:46:01 to 13:52:55.
That's right, as many as 4 moves per second!
So, I propose 2 things:
No bot or editor or administrator should be able to do more than 1 move per minute. Just reject them. That should be easy to do in software. And maybe enforcement of clearing double redirects.
No bot or editor should be able to do more than 1 edit per 20 seconds. Just queue the edit until the time has elapsed. Of course, administrators should be able to go faster, as they may be hurrying to fix a problem.
Heck, these days I often have to wait half a minute to see the response anyway. But I've noticed "edits" at a rate of 2-3 per second from "normal" editors at times, and when confronted they've claimed they aren't using a bot. Maybe not, but slow them down enough that others can notice the changes and react in human time frames.
Bug 6513
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 7/3/06, xaosflux xaosflux@gmail.com wrote:
Restrcitions like this may have unwanted affects on large legit proxy/ ISP proxy servers.
Not if they're done per username, rather than per IP.
Steve
Steve Bennett wrote:
On 7/3/06, xaosflux xaosflux@gmail.com wrote:
Restrcitions like this may have unwanted affects on large legit proxy/ ISP proxy servers.
Not if they're done per username, rather than per IP.
Steve _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
So, we should allow unrestricted editing if you're logged out, but not if you're logged in? What's the point of restricting it for logged in users if you'll inconvenience legit editors, who may then leave, and vandals will just go right on vandalizing while logged out.
Essjay
On 7/3/06, Essjay essjaywiki@gmail.com wrote:
So, we should allow unrestricted editing if you're logged out, but not if you're logged in? What's the point of restricting it for logged in users if you'll inconvenience legit editors, who may then leave, and vandals will just go right on vandalizing while logged out.
Ok, maybe we should start this discussion again, I'm getting lost. Is this about page moves or normal edits? For starters, I specifically think we should aim *not* to "inconvenience legit editors". For anons, if there is no way to tell the difference between 100 anons sharing the same IP (like a proxy) making one edit each per minute, and 1 anon making 100 edits in a minute, then I don't think we should apply any restrictions at all.
In any case, I don't really see any major benefit in these proposed restrictions on editing too fast...what problem is trying to be solved here? Restrictions on page moves could be useful, to combat the rare annoying vandal...but still.
Steve
Steve Bennett wrote:
On 7/3/06, Essjay essjaywiki@gmail.com wrote:
So, we should allow unrestricted editing if you're logged out, but not if you're logged in? What's the point of restricting it for logged in users if you'll inconvenience legit editors, who may then leave, and vandals will just go right on vandalizing while logged out.
Ok, maybe we should start this discussion again, I'm getting lost. Is this about page moves or normal edits? For starters, I specifically think we should aim *not* to "inconvenience legit editors". For anons, if there is no way to tell the difference between 100 anons sharing the same IP (like a proxy) making one edit each per minute, and 1 anon making 100 edits in a minute, then I don't think we should apply any restrictions at all.
In any case, I don't really see any major benefit in these proposed restrictions on editing too fast...what problem is trying to be solved here? Restrictions on page moves could be useful, to combat the rare annoying vandal...but still.
Steve _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
I think I have to agree with all of the above; it seems this delved off as a sub-thread of the original, discussing edit throttles rather than pagemoves. I certainly have to agree with questioning the benefit of any change at all; we're doing pretty well without any restrictions, and if a wiki is having a problem with pagemove vandalism, it shouldn't be that hard for a list full of techies (Disclaimer: I'm not one.) to come up with a pagemove-vandal-blocking-bot just like the one running on en.wiki.
Essjay
Essjay wrote:
I think I have to agree with all of the above; it seems this delved off as a sub-thread of the original, discussing edit throttles rather than pagemoves. I certainly have to agree with questioning the benefit of any change at all; we're doing pretty well without any restrictions, and if a wiki is having a problem with pagemove vandalism, it shouldn't be that hard for a list full of techies (Disclaimer: I'm not one.) to come up with a pagemove-vandal-blocking-bot just like the one running on en.wiki.
Which doesn't work well during rapid moves. Again, the proposal is to throttle pages moves to one per minute. Not hard, the move is already logged per user, and gives time to respond in the cases of abuse.
On 7/3/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
Which doesn't work well during rapid moves. Again, the proposal is to throttle pages moves to one per minute. Not hard, the move is already logged per user, and gives time to respond in the cases of abuse.
I wouldn't be keen if this applied to *all* users. I've done around 50 page moves in maybe 5 minutes - and I'm not a vandal. Sometimes you want to standardise the naming for a category. In my case, I was renaming all the French rivers from like "Garonne" to "Garonne River".
Good detection and blocking tools, definitely. Imposing a random limit on everyone because of one or two very new users carrying out vandalism? Let's avoid it...
Steve
Steve Bennett wrote:
On 7/3/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
Which doesn't work well during rapid moves. Again, the proposal is to throttle pages moves to one per minute. Not hard, the move is already logged per user, and gives time to respond in the cases of abuse.
I wouldn't be keen if this applied to *all* users. I've done around 50 page moves in maybe 5 minutes - and I'm not a vandal. Sometimes you want to standardise the naming for a category. In my case, I was renaming all the French rivers from like "Garonne" to "Garonne River".
You are asserting that you moved each page, checked for and fixed all double redirects, and changed the bold page title; personally reviewing and verifying 3 or more actions for 50 pages, all in under 5 minutes (300 seconds, a rate of 2 seconds or less per edit). Two responses:
1) There really isn't such a rush, this isn't a competition.
2) I don't believe you.
Good detection and blocking tools, definitely. Imposing a random limit on everyone because of one or two very new users carrying out vandalism? Let's avoid it...
It's not random. It brings all response times back to human scale.
William Allen Simpson wrote:
Steve Bennett wrote:
I wouldn't be keen if this applied to *all* users. I've done around 50 page moves in maybe 5 minutes - and I'm not a vandal. Sometimes you want to standardise the naming for a category. In my case, I was renaming all the French rivers from like "Garonne" to "Garonne River".
You are asserting that you moved each page, checked for and fixed all double redirects, and changed the bold page title; personally reviewing and verifying 3 or more actions for 50 pages, all in under 5 minutes (300 seconds, a rate of 2 seconds or less per edit). Two responses:
- There really isn't such a rush, this isn't a competition.
This kind of sentiment (which appears to be widespread) assumes that everyone in the world has some sort of pressing need to do something useful for Wikipedia. You blindly assume that everyone will perform the same amount of work independent of how inconvenient it is or how long it will take, supposedly because they have some inherent urge to do that work and will not be held back by any obstruction. Has anyone ever thought that if something is less convenient or takes more time, that people are by logical consequence less likely to even do it at all?
- I don't believe you.
You made several unreasonable assumptions above. He only said he moved 50 pages within 5 minutes (= 6 seconds per move). This is completely reasonable and believable. You suddenly assert that the subsequent clean-up work must also fall within those 5 minutes. Heck, even asserting that this clean-up work was done at all is unreasonable in itself.
Timwi
On Tue, Jul 04, 2006 at 07:13:08PM +0100, Timwi wrote:
This kind of sentiment (which appears to be widespread) assumes that everyone in the world has some sort of pressing need to do something useful for Wikipedia. You blindly assume that everyone will perform the same amount of work independent of how inconvenient it is or how long it will take, supposedly because they have some inherent urge to do that work and will not be held back by any obstruction. Has anyone ever thought that if something is less convenient or takes more time, that people are by logical consequence less likely to even do it at all?
Certainly.
The curve is probably even logarithmic. The linearly easier you make a process, the logarithmically more times people will use that process, would be my bet.
I know it personally applies to me.
Cheers -- jra
On 7/4/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
I wouldn't be keen if this applied to *all* users. I've done around 50 page moves in maybe 5 minutes - and I'm not a vandal. Sometimes you want to standardise the naming for a category. In my case, I was renaming all the French rivers from like "Garonne" to "Garonne River".
You are asserting that you moved each page, checked for and fixed all double redirects, and changed the bold page title; personally reviewing and verifying 3 or more actions for 50 pages, all in under 5 minutes (300 seconds, a rate of 2 seconds or less per edit). Two responses:
For what it's worth, I don't check for double redirects. I consider something them a bot could do a lot better. And they're not that harmful.
(which isn't to say that fixing double redirects is to be discouraged, it's just a way of helping Wikipedia that I choose not to perform. I figure the benefits of standard naming outweigh the temporary downsides of the DRs. And I thoroughly reject any notion that one should not do beneficial thing A because one didn't also do beneficial thing B.)
- There really isn't such a rush, this isn't a competition.
Ah, ok. So, I should probably only, like, make, what, one Wikipedia edit per day?
- I don't believe you.
What was the claim again, 50 pages in 5 minutes? Well, it turns out I only managed 5 per minute:
# 08:53, 29 May 2006 (hist) (diff) Arly (moved Arly to Arly River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) m Arly River (moved Arly to Arly River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) Armançon (moved Armançon to Armançon River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) m Armançon River (moved Armançon to Armançon River: consistency (see discussion on Wikipedia:WikiProject French départements)) # 08:53, 29 May 2006 (hist) (diff) Arve (moved Arve to Arve River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) m Arve River (moved Arve to Arve River: consistency (see discussion on Wikipedia:WikiProject French départements)) # 08:53, 29 May 2006 (hist) (diff) Ille (moved Ille to Ille River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) m Ille River (moved Ille to Ille River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) Huisne (moved Huisne to Huisne River: consistency (see discussion on Wikipedia:WikiProject French départements)) (top) # 08:53, 29 May 2006 (hist) (diff) m Huisne River (moved Huisne to Huisne River: consistency (see discussion on Wikipedia:WikiProject French départements))
But hey, it's not a race :)
It's not random. It brings all response times back to human scale.
Yay, I'm superhuman. And I wasn't even trying! Imagine if I trained a bit...
Steve
On 04/07/06, Steve Bennett stevage@gmail.com wrote:
Yay, I'm superhuman. And I wasn't even trying! Imagine if I trained a bit...
I'll put you in touch with Marvel, and the people who make those cute plastic action figures.
Rob Church
On Tue, Jul 04, 2006 at 08:28:33PM +0100, Rob Church wrote:
On 04/07/06, Steve Bennett stevage@gmail.com wrote:
Yay, I'm superhuman. And I wasn't even trying! Imagine if I trained a bit...
I'll put you in touch with Marvel, and the people who make those cute plastic action figures.
And the award for Outstanding Effort in Understated Humor In A Mailing List Reply goes to...
Cheers, -- jra
On 7/4/06, Steve Bennett stevage@gmail.com wrote:
Yay, I'm superhuman. And I wasn't even trying! Imagine if I trained a bit...
Nevermind that human response time lives in the sub-one-second range. If we had a good enough interface and fast enough servers, you could easily see people moving ~60 articles/second, doing subsecond edits, etc.
I could especially see frequent edits from someone fixing spelling or punctuation - pedantic, yes, but definitely adding value to the wiki.
Wikis are designed to be self-healing. Anything that reduces the capacity of the wiki to be edited is contrary to the nature of the wiki. This implies that there will be uneasiness - we don't always WANT things to be in flux! - but that's what a wiki is all about. It's better to have tools that can deal with that - for instance, by mass reverting a user's contributions - rather than penalizing all the innocents out there.
Also - never, never, never make assumptions about what's humanly possible or not. Physically possible, maybe. If it's a real human doing editing then they may as well go as fast as they want to, and who are we to tell them it's wrong?
Maybe what would make sense here would be doing something like stochastically requesting captchas from people doing frequent edits. Give them credit the more they answer right, so they get them less frequently. Make sure it doesn't break on massively tabbed edits. ;) Post a safe threshold under which you'll never get a captcha, so bots can fly under the radar if they go slowly.
On 7/4/06, Ben Garney beng@garagegames.com wrote:
Wikis are designed to be self-healing. Anything that reduces the capacity of the wiki to be edited is contrary to the nature of the wiki. This implies that there will be uneasiness - we don't always WANT things to be in flux! - but that's what a wiki is all about. It's better to have tools that can deal with that - for instance, by mass reverting a user's contributions - rather than penalizing all the innocents out there.
Also - never, never, never make assumptions about what's humanly possible or not. Physically possible, maybe. If it's a real human doing editing then they may as well go as fast as they want to, and who are we to tell them it's wrong?
I suppose the simple example would be: if the MediaWiki interface let me rename every single river to meet the "...River" naming convention, in one single second, would that be a good thing or a bad thing?
The answer is, "good thing". One might then argue that giving such power to vandals is bad. But that wasn't the question: the question was whether *I* should have such power...
Steve
On Tue, Jul 04, 2006 at 09:55:55PM +0200, Steve Bennett wrote:
I suppose the simple example would be: if the MediaWiki interface let me rename every single river to meet the "...River" naming convention, in one single second, would that be a good thing or a bad thing?
The answer is, "good thing". One might then argue that giving such power to vandals is bad. But that wasn't the question: the question was whether *I* should have such power...
That is *such* a good point...
Cheers, -- jra
William Allen Simpson wrote:
It amazes me, but several times in the past week, I've been blindsided by page move vandals. The current restriction apparently allows moves automatically after a week?
I'm surprised it hasn't been said yet, but the classic wiki solution to page move vandalism is not to put up barriers to making contributions, but rather to make vandalism easier to revert. I made a "revert" link in the page move log a while back, but a lot of people don't know about it, and it's far from ideal. What we really need is a big list of checkboxes on the user contribution page, with a "select all" box. Click select all, click revert, job done. The function would be restricted in the same way as rollback. With the 1.5 schema, moving pages is quite a fast operation, similar to editing.
Throttling is necessary to prevent extremely high request rate attacks, but it should be set to a level that won't inconvenience regular users. The UserThrottle extension can be adapted for this purpose.
If you can't revert page moves in a shorter time than it takes to perform them in the first place, then there's a problem with our user interface.
-- Tim Starling
On 7/4/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
I'm surprised it hasn't been said yet, but the classic wiki solution to page move vandalism is not to put up barriers to making contributions, but rather to make vandalism easier to revert. I made a "revert" link in the page move log a while back, but a lot of people don't know about it, and it's far from ideal. What we really need is a big list of checkboxes on the user contribution page, with a "select all" box. Click select all, click revert, job done. The function would be restricted in the same way as rollback. With the 1.5 schema, moving pages is quite a fast operation, similar to editing.
Oh, grouped rollback, lovely.
Steve
Tim Starling wrote:
I'm surprised it hasn't been said yet, but the classic wiki solution to page move vandalism is not to put up barriers to making contributions, but rather to make vandalism easier to revert.
I'm surprised (well, rather disappointed) that this even needs saying. It implies that most people here don't know what wiki is all about.
Timwi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm surprised it hasn't been said yet, but the classic wiki solution to page move vandalism is not to put up barriers to making contributions, but rather to make vandalism easier to revert.
I'm surprised (well, rather disappointed) that this even needs saying. It implies that most people here don't know what wiki is all about.
Well that's the situation, isn't it? Why should it be surprising that people are creatures of habit -- and this is another learned one? There needs to be more of an educational effort, clearly.
And I think there are also some baseless assumptions about what a wiki is (or isn't) here too. Maybe these are what the _mediawiki_ wiki software is -- but not wiki software per se.
- -- grok.
- -- ** FULL-SPECTRUM DOMINANCE! **************************************** * BOYCOTT BOURGEOIS * Get your news & analysis * * MASS-MEDIA: * from the Best on the Web * **** Critical endorsement only **** Most sites need donations **** * http://www.uprisingradio.org Uprising Radio * * http://narconews.com Narco News Bulletin * * http://radio.labourstart.org Radio LabourStart * * http://www.laborradio.org Workers Independent News Service * * http://www.democracynow.org Democracy Now! TV/Internet * * http://www.indymedia.org Your local IndyMedia website * * http://www.ratical.org rat haus reality * *** There can be no whitewash at the Whitehouse. - Richard Nixon *** GPG fingerprint = 2E7F 2D69 4B0B C8D5 07E3 09C3 5E8D C4B4 461B B771
On 04/07/06, grok@resist.ca grok@resist.ca wrote:
And I think there are also some baseless assumptions about what a wiki is (or isn't) here too. Maybe these are what the _mediawiki_ wiki software is -- but not wiki software per se.
The truth is, no-one is still quite sure what a wiki engine should do, because no-one is still quite sure quite what a wiki is. Yes, there are definitions all over the place; but compare my opinion, Tim's, Brion's, etc. - and then compare those to Ward's. You'd find the details would vary in small but significant places.
Rob Church
Rob Church wrote:
On 04/07/06, grok@resist.ca grok@resist.ca wrote:
And I think there are also some baseless assumptions about what a wiki is (or isn't) here too. Maybe these are what the _mediawiki_ wiki software is -- but not wiki software per se.
The truth is, no-one is still quite sure what a wiki engine should do, because no-one is still quite sure quite what a wiki is. Yes, there are definitions all over the place; but compare my opinion, Tim's, Brion's, etc. - and then compare those to Ward's. You'd find the details would vary in small but significant places.
Still, though. I'm sure the people will all agree that a wiki primarily aims to work by making it easy to revert vandalism, not by preventing it in the first instance. I just find it surprising (or disappointing, as I said) that people don't naturally extend this to any form of contribution (e.g. page moves in this case). Instead, we regularly get suggestions to slow everyone's useful contributions down. It's really frustrating to see these misguided suggestions appear over and over again.
Timwi
On 7/5/06, Timwi timwi@gmx.net wrote:
Still, though. I'm sure the people will all agree that a wiki primarily aims to work by making it easy to revert vandalism, not by preventing it in the first instance. I just find it surprising (or disappointing, as I
So, has there ever been a serious attempt at implementing a "total user rollback", undoing every change for a specific user after a specific date, where there have been no subsequent changes to the article?
Changes to make it easier for people to flag vandals would also be welcome. Currently, at en, it seems you can put a {{test}} warning on their user page, but that probably won't trigger further action. You can report it to AN/I, but I've never found that system terribly satisfactory from a user's point of view. Being able to flag edits - and by extension, editors - as vandalism would be great. Imagine a system where if 3 different editors have flagged edits by a given editor as "vandalism", it triggers some vandalism-reduction mechanism (like preventing changes being immediately public). Of course, the right to flag vandalism should be revokable to prevent its use in edit wars (and hence, only given, automatically, after some demonstration of commitment to the project...)
Just an idea of how to extend the "make it easy to revert vandalism" idea without impingeing on good editors.
Steve
wikitech-l@lists.wikimedia.org