How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Shae Matijs Erisson
Malcolm Wallace <[hidden email]> writes:

> > >  ... And avoid
> > >   getting screwed up by malicious folk?
> >
> >     ...   but I believe there are a number of people who regularly
> > review all the "Recent Changes" and undertake to 'undo' any
> > malicious/inaccurate modifications.
>
> I suspect this would end up adding /more/ work to central maintainers,
> rather than less.

Recently the Haskell Wiki went from anonymous edits to logged-in edits because
of the tremendous amount of wikispam, so I agree with this.
On the good side, it's easy to create an account.
On the bad side, at some point spambots will notice this too.

Fermat's Last Margin was originally planned to annotate images attached to wiki
pages. Someone on #haskell suggested using SVG instead, and someone else showed
me that pstoedit can produce SVG from pdf and ps files.
So, generalized markup annotation might be a good approach.

Since Fermat's Last Margin is just a darcs-backed wiki, that might be simpler.
If the ghc-docs were viewable and editable in a wiki format, and the changes
were saved to a darcs repo, then the maintainers could just pull the changes
they like, and flush useless changes like spam.
--
Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said:
You could switch out the unicycles for badgers, and the game would be the same.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Manuel M T Chakravarty
Matijs Erisson:

> Malcolm Wallace <[hidden email]> writes:
>
> > > >  ... And avoid
> > > >   getting screwed up by malicious folk?
> > >
> > >     ...   but I believe there are a number of people who regularly
> > > review all the "Recent Changes" and undertake to 'undo' any
> > > malicious/inaccurate modifications.
> >
> > I suspect this would end up adding /more/ work to central maintainers,
> > rather than less.
>
> Recently the Haskell Wiki went from anonymous edits to logged-in edits because
> of the tremendous amount of wikispam, so I agree with this.
> On the good side, it's easy to create an account.

I don't think restricting editing to registered users is a significant
turn off if registration is simple.

> On the bad side, at some point spambots will notice this too.

We can use the same techniques that web sites like slashdot.org use to
prevent bots from registering accounts.

Manuel


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Neil Mitchell
> I don't think restricting editing to registered users is a significant
> turn off if registration is simple.

It really really is a turn off. Sometimes when I spot a mistake, and
I'm at a computer where I haven't logged in to hawiki, I don't bother
fixing it. No one wants to have yet another account, to fill in their
personal details yet again.

I appreciate spam is a problem, but turning off unregistered users is
a trade off - less content, less spam, less open to people joining -
its not a free solution.

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Scott Weeks
The public comment/wiki spam problem is easily solved.

Use JavaScript to generate a value and put it in a hidden form field.
Check for that value server side, if it's there then allow the post
otherwise disallow.

Most if not all bots don't have JavaScript engines.


On 16/11/2005, at 10:15 PM, Neil Mitchell wrote:

>> I don't think restricting editing to registered users is a significant
>> turn off if registration is simple.
>
> It really really is a turn off. Sometimes when I spot a mistake, and
> I'm at a computer where I haven't logged in to hawiki, I don't bother
> fixing it. No one wants to have yet another account, to fill in their
> personal details yet again.
>
> I appreciate spam is a problem, but turning off unregistered users is
> a trade off - less content, less spam, less open to people joining -
> its not a free solution.
>
> Thanks
>
> Neil
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Shae Matijs Erisson
In reply to this post by Neil Mitchell
Neil Mitchell <[hidden email]> writes:

> It really really is a turn off. Sometimes when I spot a mistake, and
> I'm at a computer where I haven't logged in to hawiki, I don't bother
> fixing it. No one wants to have yet another account, to fill in their
> personal details yet again.
>
> I appreciate spam is a problem, but turning off unregistered users is
> a trade off - less content, less spam, less open to people joining -
> its not a free solution.

Yeah, I see your point. The problem was that each automated spam change had to
be manually undone. The latest unreleased version of MoinMoin has batch undo
features for just this reason, I'll see if I can install it onto haskell.org

Assuming I get it installed, I'll give batch-undo privileges to the most active
wiki users. Up till now Cale Gibbard, Thomas Jaeger, and I have done most of
the boring spam removal work.

I probably won't have time to do this before the weekend though.
--
Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said:
You could switch out the unicycles for badgers, and the game would be the same.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Wolfgang Jeltsch
In reply to this post by Scott Weeks
Am Mittwoch, 16. November 2005 12:33 schrieb Scott Weeks:
> The public comment/wiki spam problem is easily solved.
>
> Use JavaScript to generate a value and put it in a hidden form field.
> Check for that value server side, if it's there then allow the post
> otherwise disallow.
>
> Most if not all bots don't have JavaScript engines.

But not all users use JavaScript.

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Arthur van Leeuwen

On 16-nov-2005, at 13:14, Wolfgang Jeltsch wrote:

> Am Mittwoch, 16. November 2005 12:33 schrieb Scott Weeks:
>> The public comment/wiki spam problem is easily solved.
>>
>> Use JavaScript to generate a value and put it in a hidden form field.
>> Check for that value server side, if it's there then allow the post
>> otherwise disallow.
>>
>> Most if not all bots don't have JavaScript engines.
>
> But not all users use JavaScript.

A nicer solution might be to have the server generate a distorted image
of a key (as is done with user registration to combat automated user  
generation)
that should be typed in for an edit to be accepted (if you are not  
logged in).

Doei, Arthur.

   /\    / |       [hidden email]       | Work like you don't need  
the money
/__\  /  | A friend is someone with whom | Love like you have never  
been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody  
watching



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Philippa Cowderoy
On Wed, 16 Nov 2005, Arthur van Leeuwen wrote:

> A nicer solution might be to have the server generate a distorted image
> of a key (as is done with user registration to combat automated user
> generation)
> that should be typed in for an edit to be accepted (if you are not logged
> in).
>

This comes with accessibility issues, much as any other text represented
by images, only more so as the whole point is to fool OCR software.

--
[hidden email]

"My religion says so" explains your beliefs. But it doesn't explain
why I should hold them as well, let alone be restricted by them.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Cale Gibbard
On 16/11/05, Philippa Cowderoy <[hidden email]> wrote:

> On Wed, 16 Nov 2005, Arthur van Leeuwen wrote:
>
> > A nicer solution might be to have the server generate a distorted image
> > of a key (as is done with user registration to combat automated user
> > generation)
> > that should be typed in for an edit to be accepted (if you are not logged
> > in).
> >
>
> This comes with accessibility issues, much as any other text represented
> by images, only more so as the whole point is to fool OCR software.
>
Surely we wouldn't use captchas on edits by registered users, so
there'd still be a way for those users with vision problems to make
edits, they'd just have to log in. If people want to use captchas as
part of the process in signing up for an account, then there should be
an alternate mechanism for people with accessibility issues. I wonder
how well an audio version of the captcha test would work -- one could
probably rig up festival to generate sounds of words linked alongside
the distorted picture which blind users could listen to and type into
the field.

It's unfortunate, but if you don't put a little bit of effort into
defending your forms, they will eventually get quite a lot of spam.
Cleaning up 600+ pages by hand takes quite a lot of effort, even with
the ability to revert. Mass reverting would be another way to try to
deal with it. Another way to raise the bar a bit perhaps would be to
randomise the names of the form controls slightly, so that a spambot
couldn't just use the same names for things every time, it would have
to properly load the page and scrape the names out.
 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Scott Weeks
In reply to this post by Wolfgang Jeltsch
>>
>> Most if not all bots don't have JavaScript engines.
>
> But not all users use JavaScript.
>

I can certainly understand that some users don't have JavaScript but
it's the vast minority. The choice is between usability. With captchas
you can exclude the disabled and people with poor eyesight (as well as
those who can't be bothered trying to figure out what it says).

Those that have JavaScript turned off are generally technically
proficient because (in most cases) they've made the choice to turn it
off. So the choice is still there to post as long as you provide good
error messages.

So JavaScript is the least intrusive

Captchas are the most

In between would be a form field that asks a very simple question such
as "what's this site about? Hint: it's Haskell"

Cheers,
Scott
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Manuel M T Chakravarty
In reply to this post by Neil Mitchell
Neil Mitchell:

> > I don't think restricting editing to registered users is a significant
> > turn off if registration is simple.
>
> It really really is a turn off. Sometimes when I spot a mistake, and
> I'm at a computer where I haven't logged in to hawiki, I don't bother
> fixing it. No one wants to have yet another account, to fill in their
> personal details yet again.
>
> I appreciate spam is a problem, but turning off unregistered users is
> a trade off - less content, less spam, less open to people joining -
> its not a free solution.

It is a trade off, but I am not (yet) convinced that it is a very
serious one.  The question is whether we want to make (almost) all of
haskell.org editable, so that, for example, people can put links to
their own libraries, tools, and papers up, or that they can share other
Haskell knowledge.  Not all, but many of these things are not casual 1
minute updates anyway.  For these, moving from nobody, except two
maintainers, can edit to anybody who can bother with 1 minute
registration fuzz can edit seems already like a rather dramatic change.

Besides, I definitely have a very lightweight registration in mind.  No
personal details, except an email address required.

Manuel


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Wolfgang Jeltsch
In reply to this post by Cale Gibbard
Am Mittwoch, 16. November 2005 20:02 schrieb Cale Gibbard:
> [...]

> It's unfortunate, but if you don't put a little bit of effort into
> defending your forms, they will eventually get quite a lot of spam.
> Cleaning up 600+ pages by hand takes quite a lot of effort, even with
> the ability to revert.

Is the wiki spam problem really that big?  If yes, I would really wonder how
Wikipedia deals with it.  Since I have never come across a spammed Wikipedia
article, it's hard for me to imagine that wiki spam is such a big problem.

> [...]

> Another way to raise the bar a bit perhaps would be to randomise the names
> of the form controls slightly, so that a spambot couldn't just use the same
> names for things every time, it would have to properly load the page and
> scrape the names out.

This would mean modifying the wiki software, right?  This in turn would cause
problems with, for example, security updates.

>  - Cale

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to use a wiki to annotate GHC Docs? was Re: [Haskell] Re: Making Haskell more open

Cale Gibbard
On 18/11/05, Wolfgang Jeltsch <[hidden email]> wrote:

> Am Mittwoch, 16. November 2005 20:02 schrieb Cale Gibbard:
> > [...]
>
> > It's unfortunate, but if you don't put a little bit of effort into
> > defending your forms, they will eventually get quite a lot of spam.
> > Cleaning up 600+ pages by hand takes quite a lot of effort, even with
> > the ability to revert.
>
> Is the wiki spam problem really that big?  If yes, I would really wonder how
> Wikipedia deals with it.  Since I have never come across a spammed Wikipedia
> article, it's hard for me to imagine that wiki spam is such a big problem.
>
Wikipedia has a page just to keep track of where the vandalism is
currently happening. See:
http://en.wikipedia.org/wiki/Vandalism_in_progress
There's a ridiculous amount of vandalism going on at any one time,
it's just that the wiki is so huge that it's only a tiny fraction of
the content, and it has so many users that things move quickly.

Yes, HaWiki has been hit several times now with large spamming runs,
often where nearly every page got hit. Normally someone who is
watching with permissions to do so will edit LocalBadContent and put a
stop to it, and clean things up, but it's not uncommon to have to
clean 100 pages, and when I got home one day, every page on the wiki
had been spammed (700+), and some of them twice, once by a different
spammer. This sort of thing is what prompted making all the pages
immutable to users not logged in.

> > [...]
>
> > Another way to raise the bar a bit perhaps would be to randomise the names
> > of the form controls slightly, so that a spambot couldn't just use the same
> > names for things every time, it would have to properly load the page and
> > scrape the names out.
>
> This would mean modifying the wiki software, right?  This in turn would cause
> problems with, for example, security updates.

Perhaps the changes could be made upstream. Also, if people are
considering writing wiki software in Haskell, it's something to take
into account.

- Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe