Re: Hosting of the cookbook

>> [...] In the absence of that kind of feedback,
>> we have all been moving forward.
>
> If we don't know where the route to reach our destination is,
> how can we judge whether it is moving forwards instead of
> moving backwards while arse about face?

We have a web site which supports easy collaborative, revision controlled,
traceable editing, using a simple input format.  The resulting pages are
directly useable as an online cookbook, have good presentation quality,
and can be customized via skins and CSS stylesheets.  The output is of
sufficient quality that it could conceivably be used directly for book
publishing.

People are writing recipes using this new setup, with remarkably little
fuss, which I consider to be a validation of the approach.

Are there still questions to be resolved?  Sure.  The most important
question, of course, is whether the outstanding questions can be resolved
without major changes to the current setup.  I think they can be.

More importantly, alternatives aren't exactly jumping out at us.  A "pure
wiki" seems like a step backwards in terms of control, and I'm under the
impression others agree with that.  An annotation-based system would be an
option, but I think we have enough flexibility with the current setup to
accomodate that, if we need it.

>> I'm perfectly willing to entertain the idea that we're going
>> in a wrong direction, but to be convinced of that, I'd need
>> to see alternatives.
>
> I know you are capable of better than challenging someone
> who has described their current lack of time to build or
> research concrete examples.

I'm not challenging you.  I don't see any fundamental problems with what
we're doing at the moment, no-one seems to be advocating any specific
alternatives, and none of the ones we've discussed seem to have been
ideal.  What we do have seems promising to me - not perfect, but workable.
 So, to be convinced that we're going in the wrong direction, I'd need to
see either evidence of some show-stopping problem with the current
approach, or specific alternative proposals.

If there were promising alternatives, I'd be exploring them, but there's
been very little by way of "take a look at package X, I think it can do
what we want".  FYI, in addition to the various wikibooks etc., I did
spend a little time looking at CMS systems, like Postnuke, but I didn't
find anything that seemed to offer anything significantly better, and many
of them lack basic features we'd need.  We could use something like Zope
and develop what we need, or work on building up Moshi, but reinventing
the most basic functionality we need doesn't seem productive.

Ultimately, we're talking about web software, and nothing stops us from
plugging in whatever software we need into just about any web-based
system.  If we wanted to, we could migrate towards a Scheme-based system,
which could integrate just fine with what we have now.  What we need to
start with, though, is an infrastructure which satisfies our basic needs,
and is reasonably flexible.  I think we have that.  I'm open to
alternatives, but I'm not planning to expend much more effort looking for
them - from what I've seen, I'm not convinced that significantly better
alternatives exist as free software.

Heck, if there were some commercial package that would do what we need,
I'd be willing to chip in money.  But I have some experience with document
management and authoring systems of various kinds, and I can't think of
anything that's really going to help us.

>> I'm really not sure what you're suggesting
>> we should actually *do*.
>
> How about:
> 1. agree that a published book is our target;

I see it as one target.  Long before we reach that point, though, I expect
the cookbook to be a useful online resource.

> 2. find consensus on what the path there should look like
> (ignoring its construction);

I think our first issue would be to define consensus.  However, I think
we're a ways from needing to set up something like the Apache Foundation. 
Perhaps it wouldn't be a bad idea to have an informal voting mechanism,
though.

> 3. implement automated ways to measure whether we are on
> such a path and moving towards the target;

What do you have in mind?  If you're talking about being able to produce
metrics like "new recipes per time period", or "edits per time period", I
think that'll be easy enough.  I'm not sure that an automated mechanism is
really going to tell us the important things, though.

> 4. try to facilitate research that schematicians think
> interesting,  if there's time;

Being realistic, there are a handful of us at the moment.  One of the best
ways to increase our capacity to do useful and interesting things is to
increase our numbers.  Some of the kinds of things you'd like to do may
actually become more practical once we've made the cookbook more public.

> 5. walk;
> 6. run?

Those don't qualify as concrete suggestions.

>> Regarding output, I'm of the opinion that the cookbook's
>> structure is likely to evolve even after it goes public.
>
> We can revise things later if needed, but not even considering
> them means that revision will definitely be needed. If you accept
> that it's cheaper to fix now, then you trade a certain expense
> later for a little expense now plus a chance of expense later.
> I guess you see revision as fairly cheap later?

I see it as something ongoing, an iterative process, and one which we're
in the very early stages of.  I'm not sure what it is you think we're not
considering, that's why I keep asking for specifics.  The fact that we
haven't actually implemented a response to all the questions that exist at
such an early stage of a project like this isn't unusual.

>> Producing an HTML version
>> should be fairly straightforward using wget, as Noel suggested. [...]
>
> wget is flawed for anything more than a simplistic mirror.

What are we looking for, other than a simplistic mirror?

>> Are we deferring some work?  Sure.  But I don't think we're
>> creating a big project that wouldn't exist otherwise.
>
> You are making certain a big project which might be avoided.

I don't agree.  I've explained a bit more about my perspective on the book
organization in my earlier post.  We basically need some way of organizing
a bunch of recipes into a structure.  I'd like to improve a little on the
current setup before going public, and ensure that whatever we do is
reasonably automatable, so that it isn't difficult to convert to some
other format if that later proves desirable.  My suggestion in
AdminCookbookViews could provide that ability.

>> My feeling is that we can play all of these things by ear.
>
> So you won't discuss them in any sensible way now?

I'm happy to discuss them, but I'm not going to originate discussion on
those subjects, because I don't feel the need.  You're asking lots of
questions, but you're not saying "I think we should do X", where X is
something *much* more specific and achievable than "implement automated
ways to measure our progress".  If you don't provide such input, all we
can do is hear your concerns, and decide whether each of us personally
feels the need to do anything about them, if there's even anything we
*can* do.

>> The big point
>> here is what exactly do we have to lose?
>
> The big point is we lose time. Time is precious. Life is short.
> Man lives for but three score year and ten (or considerably
> less  if chronically ill). If you are determined to filibuster
> and deny,  then I am wasting my time on these emails even.
> Please be honest  and write "no discussion will convince me"
> rather than asking or  inviting questions which you are not
> interested in.

I'm inviting input which we can act on, because that's what's going to
make a difference.  I'm not in charge of this project, and it doesn't have
a voting system afaik.  The people who do the work get, in practice, an
enormous vote about what work gets done.  They make their own decisions
about how they spend their time.  If you want to influence what they do,
you're going to have to do a good job of providing a rationale and
recommendations for what they/we should be doing.

>>> * What do we expect to see if one of the alternative
>>> suggested development models is more appropriate?
>> I think we'll know it when we see it.
>
> You want not to discuss any objective measurement, yet
> you expect to "see" things like "a great deal of editing
> or policing"?

Again, I'm willing to discuss it, but you haven't yet provided much by way
of suggestions or proposals to discuss.  Just asking leading questions is
not enough on its own.  We've all heard and noted the questions, and some
of us have responded as best we can.  If you see problems that you think
need to be addressed, but you don't offer some idea of what you see as
possible solutions, or what kind of solutions would satisfy you, it's
difficult to respond meaningfully.  Your 6 points above still don't give
us much to go on.

> Unless you just want a free hand to act
> irrationally, I think you are not making sense.

Your perception of what we're doing is certainly very different than mine.
 For a moment, before you found out that people were actually writing
recipes, you seemed to think perhaps the current situation wasn't so
"daft".  I've explained why I don't see writing recipes now as being
problematic.  We're still in the process of finalizing some details. 
Perhaps you'll find things will make more sense once that's been done.

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