RE: Hosting of the cookbook

> > My preference is for wiki-esque free edits vs
> > privileged immutable recipes and annotations.  Why? It
> > allows recipes to be iteratively refined to
> > perfection,
>
> It also means you will never stabilise at the best possible recipe. If
> we really have an active community, it seems similar to a simplistic
> Genetic Algorithm approach to cookbook authorship.

We'll always have the option of selectively freezing pages, which Noel
mentioned, and I think we'll probably reach a point where we want to use
that.  That relates to this question:

> Have we any data to favour the assumption of "iterative revision
> will improve not decrease quality" over "some contributors will
> goof sometimes"? People edit trivially-checkable correct
> information in wikipedia to incorrect.

No, we don't have any data.  However, I think we could easily collect some,
by starting out as open as possible.  We don't currently have a lot of
content to protect, and if we don't try, we'll never know what the Scheme
community is capable of here.

> Non-working editors will hinder the book in either model.
> I don't think that is a valid argument either way.

The argument as I see it is that at least some of our contributors are
likely to be responsible, and save the editors some work, as opposed to
knowing for sure that every contribution has to be edited to integrate it.
The question is whether other, less ideal contributors will completely
offset this, or not.  I think this can partially be addressed by having some
guidelines about editing existing content.

> > - some sort of flow control to stop robots hammering
> > the site (e.g. edits only allowed every 20 seconds)
>
> That needs to be a bit more sophisticated, else quick typo fixes get
> rejected, which is really annoying. Maybe "max 3 edits a minute from
> an IP" but some spam-robots trickle edits to try to avoid being
> spotted in logfiles on busy wikis now.

I'll give this some thought, and check what other twikis have done.
However, I'm not convinced that bots signing up for accounts are going to be
a big problem at first, based on reports from other twiki sites, and also
that we're not going to be a very high-profile wiki (at least until the
cookbook starts competing with J2EE and we're indundated with millions of
desperate Java and C# developers...)  Seriously, in this area too, I believe
we can try it out and see how it goes, and evolve our defenses over time.

Here's a semi-tongue-in-cheek idea, which solves both the bot problem and
the poor contributor problem in a single stroke of genius: to sign up, ask
contributors to answer a tricky question about Scheme or a small Scheme
program.  If they fail, give them simpler questions until they pass.  Assign
them full edit vs. annotation privileges based on how well they do.
Assessing spelling capability might also be a thought... ;)

Anton



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click