Difference between revisions of "WikiIndex talk:Spam control policy"

Revision as of 09:39, 26 January 2012

Level 3.5 - CAPTCHA

I've just been experiencing this over at WP. Not fun, but perhaps a reasonable compromise. But I'd rather not be forced through a whole additional screen; I might rather be served a CAPTCHA on every edit page, that I can fill in with the edit if I know I will need it. If I forget, then it can give me a nag screen. And I notice on this wiki that mostly the problem is whole page-fulls of link spam. Which makes me think, what about a whole additional CAPTCHA nag screen for each link? And then, what about "first link free"? Having the ability to fine tune such parameters might make it fit the needs of each wiki better.--69.87.193.16 17:44, 21 February 2007 (PST)

I have installed reCAPTCHA on my site, and have not suffered any vandalism since. -- Carl McBride 09:46, 30 August 2007 (EDT)

I believe reCaptcha has been cracked. Many sites that are using it are reporting increasing spam. Maybe FancyCaptcha would be a better option? (I've seen discussion of this on the mwusers.com forums) Gwsuperfan 23:38, 4 July 2011 (PDT)

Level 4 - Login to Edit

John, thanks for your efforts to organize this. My feeling is that although spam is an ongoing issue, it is under control here. The half life is short, and it seems like we are catching just about all of it, quite quickly. It is good to get this education about what mechanisms are currently in place, and what the potential tools are for improvement. (I am doing a fair fraction of the initial spam blanking. May have to eventually have more of an official role. But it is good to try to have a system that random anons can be a helpful part of.)

I urge that Level 4 - Login to Edit be resisted as long as we possibly can. This is a wiki where that would be especially undesirable, since I presume our reference standard-issue contributor would be creating one article here, about a specific wiki that they are interested and/or involved with. Any impediment to open anon editing would seriously discourage casual one-off contributions. (Casual involvement can grow more serious over time. But the higher the barrier to initial involvement, the smaller the number that will ever bother.) *** A theoretical, technical solution would be invisibly-moderated anon edits. Anyone could make any changes, as now, but if you are not logged in, all of your edits would only be visible to you, until an admin (could be just any logged-in user) approves them. Such a concept would be way too much development effort to implement just for wikiindex, I assume, but of such general utility that it seems worth pursuing, and maybe it has already been done somewhere? Seems like it would work fine for ordinary articles, esp with our low traffic here. (If time passes before the edits are approved, if the article has been changed by someone else in the meantime, the edits would have to be manually re-applied, or dumped.) Would be a problem for the meta-articles, policy etc, where you could easily get edit conflicts; so for such articles, maybe instead the articles could be locked to anon edits, but the associated talk pages open.--69.87.204.63 11:49, 19 February 2007 (PST)

I agree that we should hold off as long as possible on Level 4. I have been tweaking the controls (Level 1) over the last few days to improve the initial blocking and restarted the local list (Level 3) and checked that the WikiMedia list (Level 2) is working like it should. My experience in dealing with spam is that once it reaches a certain level people dealing with it start to burn out and my goal is not to ever reach that level. I think I prefer the Level 4 controls to moderating all edits, that would be a pain. Thanks for your input and spam killing efforts. John 13:00, 19 February 2007 (PST)

I like your "technical solution". I think it could be useful at all kinds of wiki, not just WikiIndex. So I made sure it was described at the wiki for that sort of thing: WikiFeatures:StagedCommits. (You might be interested in other anti-spam ideas at WikiFeatures:DelayedCommits and WikiFeatures:RejectDuplicate).

Please edit those pages if I've missed some crucial implementation detail.

--DavidCary 20:24, 19 February 2007 (PST)

Very interested to learn about "Wiki Features wiki"; I contributed my 2 cents to the article, and hope to explore further -- makes good complement to WikiIndex! But surprised to see no copyright clues on the edit page, at all, nor any apparent links to any such. (Also, had some problems with edits timing out. And just everything being different, not being MediaWiki...)--69.87.193.16 17:38, 21 February 2007 (PST)

Alas, WikiFeatures has moved to a new host, breaking all those links. I wish WikiFeatures were on the intermap -- then we could fix the hostname in one place, the intermap, and all those links would start working again. How do I get WikiFeatures on the WikiIndex intermap? --DavidCary 14:57, 1 February 2011 (PST)

Delayed anon page deletion

To lessen the load on admins, it would be an interesting experiment to allow even anons to delete pages. Since this would be too much power for non-loggedin users, what if blanking a page, or some other special minimal contents, started a page-delete count-down clock, say about 24 hrs, after which the page would auto-delete. If anyone did any edits to the page in the meantime, the clock would reset -- or go away, if the page were given real contents.--69.87.199.193 12:51, 22 February 2007 (PST)

What happens if spam slips through

Sysops can block the IP address of spammers, but is there any way that a user page could be marked as a suspected spammer, in order to get a sysop to come and check the account out? David Shepheard 04:30, 27 October 2010 (PDT)

The answer is found in the last section on the project page - what happens if spam slips through the automated systems - basically just copy and paste {{spammer}} onto their user page and this will create an automated warning banner. 78.32.143.113 01:13, 21 December 2011 (PST)

spam - do you 'undo' or 'rollback' on existing valid articles

An interesting consideration . . . looking at some edit histories of articles I update, I notice that when spam has been discovered, the edit gets reverted by using the 'undo' function. This can have a problem, in that the spam is still there in the article (by using either the 'diff' or the timestamp). This may not be a big problem to generic trivial spam, but for more contentious spam (such as illegal activities, child porn images, etc) this can be a real problem. So can I suggest that when spam is added to existing articles, the admins use the 'rollback' function instead - as this then permanently deletes the offending spam edit, and wont then show up in the articles edit history. --Hoof Hearted • talk2HH 01:39, 26 January 2012 (PST)