[Haskell] Re: Making Haskell more open

[Manuel M T Chakravarty]

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