RE: Hosting of the cookbook

On 2004-04-07 19:55:46 +0100 Anton van Straaten 
<[email protected]> wrote:

> [...] 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.

I don't see a significant difference between PureWiki and 
annotation-based in this respect. People will get it wrong sometimes, 
both ways.

> [...] 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.

I think we should plan to deal with this likely case before it happens.

We always put up barriers. We need to choose which ones.

>> [...] 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.

I agree with you that it's a compromise. However, access controls do 
not prevent attacks. Any control sufficient to deter attacks will also 
deter contribution. Ultimately, you cannot prevent all attacks. 
Maintenance is unavoidable.

> 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.

Sure, work is unavoidable. To me, ticking a list of contributions for 
junking seems easier than figuring out how to drive the revision 
controls or editing out inserted rubbish.

> 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 want to understand what is needed a bit more before rushing in and 
implementing. We're already throwing one away, after all.

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

Most of the developed books there appear to have only a small number 
of authors (typically 1 or 2), or have been imported from external 
non-wiki developments.

>> 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?

Whatever we choose to release as. Printed versions have been 
mentioned. Tarballs/packages seem another obvious one.

> For online purposes, making a stable
> release could be as simple as a snapshot of the pages at the point 
> we're
> interested in. [...]

Would this have dead links to wiki controls?

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

We should learn from their mistakes. I am sure many books are released 
with less pain than their description, which suggests that the 
PureWiki defers a lot of work. We could end up with a fine development 
edition and no way to cut reasonable releases. I think that depresses 
projects.

-- 
MJR/slef     My Opinion Only and possibly not of any group I know.
Please http://remember.to/edit_messages on lists to be sure I read
http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [email protected]
  Creative copyleft computing services via http://www.ttllp.co.uk/


-------------------------------------------------------
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