RE: Hosting of the cookbook

MJ Ray wrote:

>> There's very little to learn. [...]
>
> There are specific non-wiki concepts to learn.
>
>> I think the point with TWiki is that some of the utter
>> simplicity of ordinary wikis is traded off for greater
>> ability to manage the content.  I think you might find
>> that TWiki actually addresses some of the concerns
>> you've raised.
>
> I might, when I have time to penetrate the jargon, but
> how does this agree with the "wiki is lightweight"
> reasons?

It's a tradeoff.  We're already significantly more lightweight than we
were, and I find it hard to imagine being much more lightweight while
still maintaining some modicum of ability to manage the content
effectively.  I'd be happy to be proved wrong.

>> [...] The unresolved
>> issues mainly relate to how to structure the coobook for both
>> online viewing and other publishing formats.
>
> ...that is, how to actually use the entered data to produce
> what I thought was the desired output?

We mainly seem to be talking about arranging a bunch of recipe pages. 
It's not rocket science.  I can't think of any strong reasons not to be
writing recipes while we improve the organization aspect, for example.

> Why not call a page a page? Or does this split jargon arise
> because there are pages which aren't wiki pages?

I would guess it's because "page" is ambiguous and could apply to any web
page anywhere.  Also, the term "topic" reflects a focus on content, rather
than presentation.  Topics can include other topics, so the topic<->page
connection is not perfectly one-to-one.

>> Not sure what you mean by "being fed back into the schematics
>> sources". Which sources?
>
> The CVS ones held on the schematics project site that this was
> seeded with.

Afaik, the original WebIt sources are now essentially obsolete.  I'm not
aware of any plan to convert back to that format.  We could easily store
either the TWiki source pages or the generated HTML in the CVS if that's
considered desirable.

A point about the source format being TWiki's: a big reason I'm not very
concerned about format conversions in future is that the source format in
TWiki, much like other wikis, is such a basic, almost plaintext format. 
The recipes written so far consists mainly of headings, paragraphs, some
very basic text formatting, and blocks of source code, and is easy to
parse automatically.

At the same time, the output is sufficiently well formatted as to produce
something that could conceivably be used directly for printing to PDF, and
possibly even for book publishing - for example, using a CSS stylesheet to
produce the desired fonts and other formatting required by the book. 
However, if some kind of conversion is needed for the book publishing
case, I don't see that as being particularly problematic, because the
format is so transparent.

>> [...] What's our worst-case scenario?
>
> At a guess: everything entered into the site needs to
> be rewritten in a format useful for producing a cookbook
> release and, unnoticed, no-one does that work while
> Evil Geniuses find some way to subvert the cookbook,
> replace recipes with useless-but-sensible-looking ones,
> introduce hard-to-remove spam and remove the old revisions.

I've addressed the format question above.  My feeling is that producing
book-style output is something we're going to have to pay ongoing
attention to, as the cookbook evolves.  If no-one does that, then sure, we
could have problems.  The solution to that is: let's pay attention to it. 
If you feel some more formal process is needed here, it's up to you to
either suggest an approach, or convince someone else to come up with
something.

As for Evil Geniuses, afaict the revision control doesn't allow you to
remove old revisions without administrator access to the host machine. 
Mirroring to the Schematics CVS might also help there, or some of us could
keep individual backups.

As long as we're not using an annotation approach, we'll need to keep an
eye on recipe quality.  TWiki has some tools to support that, such as the
ability to email lists of changed topics and new signups, and of course it
supports an RSS feed.  If recipe quality seems to be being compromised,
then certainly switching to an alternative control mechanism would make
sense.  Once again, on the subject of how we know we've reached that
point, if you feel we need formal guidelines, go ahead and propose some.

Anton



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297