This page is for general discussion about the content of this site. Ok, so what's the policy about moving non-free-software stuff from cliki to alu? I suppose it's rather clear for proprietary lisp software. But what about fringe stuff like the Henry Baker page, or Lisp NG? What about "personal pages" of CLiki contributors? (Hey, I just used a different nickname between here and the original CLiki.) -Far¨¦?
CLiki is "a collection of links to and resources for free software implemented in Common Lisp and available on Unix-like systems" The ALU wiki is "produced by the ALU with and on behalf of the Common Lisp users and vendors community"
Neither of them is a Geocities replacement. If all that you want to tell the world is that you're 23 years old and like Javascript/gangsta rap/mountain biking/star trek/cats, you can probably get web space from your ISP. See this comp.lang.lisp post for more details, and exercise your judgement and good taste.
Dealing with spam
A few thoughts^H^H^H^H^H^H^H^Hrants by Paolo Amoroso:
- Whys is it so difficult to revert a page to a previous version? This makes removing spam more difficult. There are no explicit links to previous versions and, when a previous version is accessed, there is no edit button.
- If people provided meaningful change logs, it would be easier to spot spam edits in the recent changes page. Something like "das" or "date" does not qualify.
- If people provided their real name (or a nickname well known to Lispers) when editing pages, it might be easier to spot spam edits in the recent changes page. Yes, I do know about the rationale for anonymous edits (see: Discuss:Implementation), but I'm still not convinced.
How can it be made easier to revert pages? If you know of a system which does this in a manner you like, leave a URL here and we can investigate implementing it.
There are a number of things we are considering to address the spam problem. They are from easy to hard:
- Reinforcing the existing CAPTCHAs with questions saavy Lisp users could answer such as solutions to bignum arithmetic expressions, etc.. Anyone care to propose an algorithm?
- Content filtering to eliminate the pesky zero pixel divs and their enclosed text.
- Non-HTML markup (or a restricted HTML markup) which formats links according to the NoFollow anti-spam inititive.
An easier user interface for reverting pages is that provided by the original CLiki.
Fighting spam by deleting it doesn't seem to work very well. We'll need to find a way to prevent it, or at least to decrease it's efectiveness, so that spammers give up by themselves. Spammers will spend their time elsewhere, if external WIKI links are ignored or cannot be followed by search engines, right?
I was thinking about using some kind of a proxy for links like a dedicated server or simple javascript, which the web spiders don't understand and can't follow. I didn't know about the googles initiative though, but it's definetly worth considering. What about yahoo, msn and other search engines? Will they follow the instructions or will they follow the link?
One bad consequnce is, that we won't be able to promote worthy pages either. I'm thinking about having registered users, which can use normal links. These registrations can be distributed by other chanels, e.g. comp.lang.lisp to well known and trusted indiviuals. Or we can just live with that, I guess.
Another wild thought is to use Bayessian methods, which are very effective against email spam. But I don't know how to apply them to a WIKI. Any ideas?
rel="nofollow" (supported by at least Google, MSN and Yahoo) along with other attempts to poison the spammer pagerank ecosystem don't stop spam now. The only hope they offer is to slowly deprive the spammer ecosystem of the energy ($) it needs to continue, but this is a very long term bet, and not everyone thinks it will pay off.
I've created a mockup of a special anti-spam tool.
The idea behind the tool is that most of the ALU wiki's current spam seems to come in bursts, from a single IP address. Recent changes are grouped by IP address, and there is a single button that can be used to undo all of the changes.
I used data scraped from Special:RecentChanges for the mockup, and it seems to support the idea that bursty single-IP spam is common.
To help avoid version conflicts with someone else who either used lower-tech methods of spam removal or otherwise edited a spammy page after it was spammed, the interface displays the version number of changes that are the most recent change for a page in bold, and others in a faded color.
Hitting the "undo ultimate" button would revert all changes with bold version numbers to the most recent version before this IP's change. The idea is that if someone spams five pages, and one has been modified since the spamming, you can hit "undo ultimate" to automatically revert the other four pages. The fifth page could be fixed manually.
The tool isn't meant to be a general solution to spam, just to help with cleaning up the kind of spam the ALU Wiki currently faces.
Any comments?
2005-24-11 Ivan Toshkov
How shall we stop the spammer to use the tool to revert the despammination? :)
2005-24-11 John Wiseman
I did think about that a bit. I guess that...
- 1. At least it would be easy to de-spam the re-spam
- 2. The spammer's IP could be blocked, which might lower the incidence of respamming.
Still, it's true such a tool would provide a lot of batch editing firepower. Though it would be difficult for it to be used to spam as such, it could be used for more general abuse/vandalization. Which leads me to...
- 3. Restrict use of the tool to some sort of trusted group.
I tend to believe that the benefits of a simple user registration system greatly outweigh any disadvantages. In particular, I think they offer more benefits and fewer drawbacks than a captcha that's required for every edit...
2005-11-25 Ivan Toshkov
I agree that it's worth trying user registration, but we'll have to think how the spammers can go around this and if it won't actually make things easier for them. E.g. now the spammer have to spam each page manually. In the new environment, it may be that he only needs to register manually and then use a script.
Another issue is that they started to put links in "Summary" field and Kiwi happily renders them. This should be easy to fix.
2005-11-26 kiwidev
We would be happy to setup a user registration system for kiwi-despots who would have access to a privledged set of despamming tools. (It would also be nice for people to register their user names to certify their edits.)
2005-11-26 Tayssir
Spam filters might be possible. You could for example not show potential spam versions of a page until it's checked by a fairly trusted user. When someone wishes to edit an unchecked potential spam page, they can be shown diffs and have the opportunity to edit what they consider a non-spam version. (Or just have the simple "burden" of reverting first, if it is spam.)2005-11-28 Gary King Joel Spolsky has a nice discussion of social software engineering in this old essay. In it, he suggests making it so that spammers continue to see their spam when they log in even though it is removed from everyone else. This might be a pain to implement but it would help prevent the sort of back and forth spam/despam battles we see now.
2006-05-30 I'm adding ALU to the list of all public wiki -- hope you don't mind. -- DavidCary
2006-06-04 Seems like it might be a bad idea to have us listed on a list of public wikis. Easier for spammers to track us down that way. Right now we have only a very few spammers. With the wiki on a public list, I fear we could have hundreds... Also, what is the use of publicizing the wiki among non-lisp-users? I'm all for publicizing the wiki on lisp-related web sites but advertising to non-lisp-users seems to just be inviting trouble. If the benefits of publicity don't outweigh the harm then we should seriously consider removing the wiki from lists of public wikis that are not directly associated with lisp. -- Daniel Finster
On this wiki, "ALU" stands for "Association of Lisp Users". (Rather than "arithmetic and logic unit").
