Strategy for deleting wiki spam pages

Christian Stimming christian at cstimming.de
Sat Aug 10 17:13:31 EDT 2013


Hi John,

I noticed you regularly delete spam pages in our wiki, which is a very good 
thing to do. As you and I and hopefully others have noticed, we now get 
approx. 1-5 spam pages created every day, which have to be deleted manually. 

This is even though new pages can be created by users who have been registered 
for more than x days. However, once you check the RecentChanges with a view 
mode that shows the new user registrations, we notice that every day there are 
approx. 50 new users being registered! Some of these will stay silent for a 
few days, then - after the waiting period is over - create the spam page. This 
way, the waiting period does nothing more than reducing the spam rate, but it 
doesn't cut it off completely anymore. This is the same for several months by 
now.

I also don't have a good solution for this. I think I can contribute to a 
check of  the RecentChanges every 1-3 days, so that this spam is deleted 
manually. (The keyboard shortcuts help a bit: Alt-Shift-D for choosing the 
page's hyperlink for "Delete this page", then Ctrl-A, Del for deleting the 
deletion reason, then Tab-Tab-Enter for really pressing the delete button, and 
all this with many browser tabs in parallel between which I navigate with 
Ctrl-PgUp/Down.)

However, I noticed in your spam deletions that you deleted only the normal 
pages, but not the user pages of those spammers. Probably you look at the 
RecentChanges page only with the subset of "Namespace = (Main)". I look at 
this page with the choice "Namespace = all". The backside of this is that I 
see those 100 new users every day and the edits scattered in between. The 
upside is that I see also the newly created spam userpages (in the "User:" 
namespace), and then I delete those as well. Do you think you can check for 
those as well, or do we need other solutions for this?

Other wikis around have disabled the normal user registration altogether for 
this very same reason, see e.g.  http://elinux.org/Main_Page  . Maybe this is 
a possibility for us as well? The vast majority of edits in the actual content 
is done by known developers from here. By this, we can argue that an increased 
restriction of the write access doesn't do much harm, but would make our life 
a lot easier.

Regards,

Christian


More information about the gnucash-devel mailing list