RE: Hosting of the cookbook

MJ Ray wrote:

> On 2004-04-05 19:37:46 +0100 Anton van Straaten
> <[email protected]> wrote:
>
> > That's a good point.  But won't this mean that it becomes up to the
> > editors to integrate new material, so instead of working to "police"
> > contributions that don't fit, some work will have to be done for
> > many or most contributions, even good ones, to make the cookbook
> > hold together rather than be a ragtag collection of random
> > contributions?
>
> Probably, but someone needs to tend a pure wiki to do that anyway.
> If this is a wiki with "schematics" on it, they ought to become a
> schematician if they will do much editing, surely?

If they will be doing much editing, I think it would be helpful if they
create an account so they're identifiable and accountable in the revision
control.  What other requirements should there be to be a schematician?

> > I've seen sites with such random collections, and they're not that
> > useful because there may be ten solutions to a given problem, and
> > most or all of them might suck.  Someone has to do editing work to
> > correct that.  If the original contributors are responsible and
> > sensible, they can do at least some of that work.
>
> I think you missed "with sufficient time" from the list of
> requirements for contributors.

The kind of thing I was thinking of is this: when adding a new recipe or
other topic, contributors will need to find a chapter or section to include
it in (or it'll just float undiscovered until someone does that).  In that
process, they may notice if there's other material which duplicates what
they're trying to add.  This potentially avoids the problem of ten people
submitting solutions to the same problem, and makes it more likely that
existing solutions will be enhanced.

> Regardless, wiki-ness doesn't prevent "someone has to do editing work
> to correct that" if you get ten partial solutions. Wiki-ness also
> introduces the possibility that the non-sucky solutions will be edited
> to suck and someone has to edit them again, too.

True.

> > It comes down to how much you trust the contributors. [...]
>
> I disagree. I think I do not distrust the contributors more than you.

Perhaps the correct word is optimism, as opposed to trust.  I suspect that
we won't have to worry a lot about non-sucky solutions being edited to suck.
Legitimate contributors are likely to recognize good material, and be
reluctant to mess with them.  If that does become a problem, it would be
possible to institute additional controls.

Twiki does support per-topic access control, so it would be possible to do
something like "bless" a topic as having reached a state of non-suckiness,
make it only editable by selected editors, and require that any additions or
annotations be made on a separate topic (which could be included in the
original topic).  But my feeling is this should only be a fallback plan in
the event of problems, or something we consider when we have more experience
with the book, and when there is more content to protect.  Otherwise, it
just seems as though we're putting up barriers in the way of people making
effective contributions.

> Rather, I believe the pure wiki is requiring more effort from both
> contributors and editors than an annotation-based system.
> The requirement was to make this thing easier and I don't think a pure
> wiki solution will. My experience with other open project wikis (the
> local LUG, Oekonux, GNUstep, Koha, Gobo, amongst others) suggests they
> require active maintenance and will be subject to attacks.

To me, this seems like another argument for some minimal access control.

> Even if all
> contributors are friendly, there will be script-based attacks on it.
> Please consider this experience even if you don't agree with my
> interpretation if the time demands.

As always with security, there are conflicting requirements here.  To
mitigate attacks, access control is needed at some level.  Two contrasting
approaches we've discussed are: a restricted list of authorized editors who
can edit the main content, plus unrestricted ability to submit annotations
or similar; vs. requiring all contributors to log in in order to make
changes, but allowing them to edit anything.  As I mentioned above, some
intermediate approaches are possible, e.g. the latter model with some pages
being more restricted than others.

Any model that supports completely anonymous contributions is going to have
more of a problem with attacks and other abuse.  That even applies to the
"protected content + anonymous annotations" model; it's just that in that
case, the protected content isn't compromised by abuse.  Work will still be
needed to deal with abusive contributions.

My personal feeling is that I'm more concerned about allowing any anonymous
updates, than I am about legitimate contributors screwing things up.

I just want to make clear: I don't care whether we use a wiki, or whether
it's TWiki.  AFAIR, other than Moshi which doesn't yet have everything we
need, nothing else specific has been proposed.  I'm trying to facilitate
getting this done, because I'm interested in the goals of the project, and I
happened to have something set up that seemed like a pretty good match for
what Noel described in his "Future of the Cookbook" message.  Having
proposed TWiki and provided an installation of it, I feel a responsibility
to help make it work.

BTW, regarding Wiki-based books, Noel originally gave this example:
http://wikibooks.org/wiki/Main_Page , to add to the list.

> I don't understand the plan for making stable releases of a pure-wiki
> cookbook. Are we deferring work for later?

Do you mean the printed version?  For online purposes, making a stable
release could be as simple as a snapshot of the pages at the point we're
interested in.  For printing, we don't yet have a solution for automatically
generating a complete table of contents from a hierarchical collection of
topics.  However, I'm looking at the TocPlugin for that purpose right now.

As the Python Cookbook example indicates, a printed book is likely to
require some manual filtering and formatting anyway.

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