On Fri, Jun 10, 2011 at 5:58 PM, Thomas Kluyver <takowl@gmail.com> wrote:
> Then this is a failure in the software. Newer versions of Moin seem to be
> able to have CAPTCHAs, and there various other things you can do about spam:
>http://www.mediawiki.org/wiki/Manual:Combating_spam
Yes, that's certainly true (though that's a mediawiki page, similar
things apply to moin). The moin on scipy.org is ancient, I'm sure
current versions at least have captcha (for the record, it might be
possible to enable it on the scipy moin, it's just that dealing with
so many old libraries there is too painful to consider).
>> I don't know where in that continuum of zero-to-infinite spam a
>> captcha system would put us. Honestly, it doesn't seem to me that
>> asking people to send a single email for human authorization is a huge
>> burden that is really causing us to lose us a lot of contributors, and
>> it does cut *completely* the spam problem. But perhaps it is causing
>> them to go away...
>> It's not so much that it's a burden. It's just that when you see a paragraph
> that's out of date, or a broken link, or whatever, and you can click edit
> and fix it immediately, people do (some people, anyway). If you've got to
> set up an account, then get someone to give you edit permission...never
> mind, there's better things to be getting on with. It's for a similar reason
> that I advocate using an existing, popular site like Github. If I have to
> register for a new account, or spend two minutes guessing which password I
> chose for this site two years ago, the chances that I will bother decay
> exponentially with the time I expect it to take.
Yes, that's true. I'm all for finding whatever balances ease of
use/contributions with burden on maintainers. Because while it's very
important that we make it as easy as possible to contribute, we really
don't have the time to be doing spam cleanup frequently. We've had
users in the past who have kindly helped with that boring task, but
I'm not sure we want to rely on that, as I think that's a waste of
*anyone's* time, not just mine :)
> Maybe this is a solution, if we have a ruby-capable server somewhere: have a
> github wiki mirrored somewhere else, so we can link to it (read-only)
> without the github branding.
>http://smeagolrb.info/
We can use the dreamhost setup for that, though it's a simple shared
host with limited cpu quotas. But I can't imagine that kind of static
mirroring being very cpu intensive.
Let's think what the requirements are for a wiki for us:
- reST support.
- images/attachments.
- search function
- spam control
- low barrier for new users to contribute (use existing authentication
or allow on-the-spot editing with good captcha or similar).
- ease of deployment and ongoing maintenance for the team (we have
preciously little time for all of this, so even moin loses big on this
front vs. github, which is already done).
What else?
With clear criteria we can see what meets which from the tools
available, and then decide on the best compromise (likely nothing will
be perfect on all).
Cheers,
f