Tomasz Zielonka: > On Fri, Nov 11, 2005 at 03:19:27PM +0000, Duncan Coutts wrote: > > > I cannot imagine that a couple of people is sufficient to review all > > > recent > > > changes and therefore I don't think they do it this way. There are some > > > typical articles where screwing up happens often, so these articles might > > > be > > > regularily revisited. Screwing up of articles might as well be removed > > > by > > > ordinary people who discover ugly things in articles by accident. > > > > One possability here would be to have all changes to the wiki reported > > in real time (or near real time) in the #haskell IRC channel. The > > #haskell lambdabot could be extended to do this. > > > > The #haskell IRC channel is active nearly 24 hours a day and has a > > membership that varies between 170 and 200. This would easily be enough > > eyes to spot malicious or inaccurate changes. > > I think that the amount of changes that need to be reviewed could be > dramatically reduced if we create some trust management system, for > example we could trust changes made by authorized users. The users > who most often contribute to the Wiki will probably be the same who care > about reviewing changes and they probably won't mind to log in, so their > changes won't have to be reviewed.
But changes of authorised users might be even more interesting to have a look at if you want to stay up to speed on what's new on haskell.org. I think, Duncan's plan is a good one. Use a convenience (real-time notification on possibly interesting web content changes) to increase the likelihood that somebody looks at a malicious update quickly and corrects it. Personally, I am not very worried about abuse of a wiki. Haskell is not a very controversial topic (...ok, maybe some disgruntled C++ users might hold a grudge ;) and pages that a particularly attractive for abuse (such as the front page) also get a lot of hits by users who can remove malicious content. Besides, we could always start of with changes to a few key pages (such as the front page, the language definition, etc) being restricted to authorised users and all the rest open. If this work well, we can always consider to be more permissive about the key pages, too. One easy way to keep spam bots out is to restrict the edit capabilities to registered users, but make registration a trivial process to keep the barrier to entry low. By using the standard email verification process for registration and a changing image from which you need to read of some letters, we can make sure that all registered users are indeed human. These are standard procedures on many web sites. Manuel _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
