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