Re: Hosting of the cookbook

MJ Ray wrote:

> On 2004-04-22 21:57:03 +0100 Anton van Straaten
> <[email protected]> wrote:
>
>>> 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.
>
> "Show alternatives" and "I don't see a problem" seem common refrains
> in this thread, repeating frequently.

Those refrains haven't all been directed at you, and they're challenges
only to someone who wants to take them up.  Many of the things you quote
me as saying just express the way I see the current situation, e.g.:

> alternatives aren't exactly jumping out at us.
> no-one seems to be advocating any specific alternatives
> If there were promising alternatives, I'd be exploring them, but

I stand by all of those statements.  If you're taking these as me
challenging you personally, you're missing my point entirely.

In other cases, you've raised points where I have no idea what you have in
mind, and I've tried to get clarification on those points.  This hasn't
just been about suggesting specific solutions, but even when it comes to
discussion: you've posed questions without offering an opinion on those
yourself (other than a sort of implicit one), and without giving much to
go on as to what you have in mind.

I'm finding it difficult to respond to those questions.  When I responded
to some of them with "we can play that by ear", you feel I'm stonewalling
discussion.  I'd love to have a *discussion*, in which we exchange
opinions and perspective on some of these matters.  I don't feel that this
is what's been happening on many of these points.

>>> 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.
>
> There are other sorts of publishing (online) and other benefits than
> the ultimate target.

I think we agree that an online resource and hopefully ultimately a
published book is our target.  I'm not sure when you say "published book"
and "publishing (online)" whether you have something more in mind than
what we're currently working towards.

>>> 2. find consensus on what the path there should look like
>>> (ignoring its construction);
>> I think our first issue would be to define consensus. [...]
>
> http://www.dict.org/

I like the m-w.com definition, "the judgment arrived at by most of those
concerned".

>>>> 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?
>
> An online book.

OK.  What is it about what you consider to be an online book, that would
not be addressed by the kind of site layout we're currently working
towards?  Is there some way in which a simplistic mirror of such a site
would not meet the requirements for an online book?

From my perspective, the Twiki site will make an acceptable online book. 
We may want some features like having next page/previous page links, and I
don't think we'll necessarily have that at the outset, but it's certainly
achievable.  Ordinary mirroring should work fine for a site like that.

>> I've explained a bit more about my perspective on the book
>> organization in my earlier post. [...]
>
> Is it accurate to paraphrase it as "We'll figure it out some
> other time"?

No, not at all.  We're figuring it out right now, and anyone is welcome to
get involved to whatever extent they wish.  My goal, as described in the
AdminCookbookViews topic, is to come up with a better solution for
organizing the recipes and producing what I'm calling index pages, without
requiring contributors to have to make changes in multiple places to add
new recipes.  I think that with this issue resolved, we will have
something that can support contributions from a larger group.

I'm not looking to make this organization mechanism into a big project.  I
think it can be kept small, simple, and focused on producing what the
cookbook needs.  If it turns out to require too much work to be done in
the near future, then I think we could get away with something like the
current approach, using the Twiki %TOC% tag to build index pages. 
However, I see some disadvantages to that, which could turn into
management problems.  The general problem I'd like to avoid is having
index pages be free-format wiki text, since that makes it more difficult
to organize the book, and produce more than one view of it.

The aspect of this which falls into the category of "we'll figure it out
some other time" are things which become necessary as the project develops
- responding and adapting to needs which become apparent.  Although we can
anticipate some of those, we can't necessarily correctly anticipate their
relative importance.  Overplanning and underplanning can be equally
time-wasting.  We need to strike a balance, which will be determined in
part by the resources we have available, which also means that it's likely
that many compromises will have to be made.

> I'm asking questions because if no questions are asked, then there is
> no understanding. I cannot give SMART targets, because there is no
> definition worth the name yet. There's no point having us all posting
> "I think we should do X" with no reasoning as to why we should be
> doing that.

Great, please feel free to give your reasoning, too.  I've been trying to
do that as best I can, myself.

> There's even less point all doing what we think we should,
> but that doesn't stop it.

I disagree on that.  There've been a bunch of good recipes written, with
very little coordination or discussion.  I don't see a problem with that. 
As I've said, I think we can support those recipes in future iterations of
the cookbook, even if we change formats.  I'm willing to work to make sure
that happens, although I don't think much work will be involved.

> 	"It is clearly visible that something is happening! But are the
> right things being done? Are they in the right order? You can never be
> sure until you discover what has been done or what assumptions have
> been made in error! Then you are faced with rework which takes up much
> time and effort.
> 	"Think of planning as an investment to save time later." -- Trevor
> Young "To Plan a Project" Kogan Page.

Right.  Having led some significant software projects, I think I have a
reasonable handle on such things.  However, part of what we're dealing
with here is that we can't verify all our assumptions up front, and we
can't be sure that we're doing the right things.  A lot depends on what
the tools we have available are capable of, and also on what happens after
we announce the site.  A common way to deal with these kind of unknowns in
real-life projects, software or otherwise, is to start with a small
solution and iteratively refine it until the desired goal is reached. 
It's often happens that the final achieved goal is somewhat different from
the way it was initially conceived, usually for reasons that would have
been difficult to predict.

Developing and refining an initial solution helps even the developers to
determine what is and isn't important.  In the end, it may turn out that
the line between "prototype" and "final product" is nonexistent.  OTOH,
the first prototype might need to be thrown away.  You may see that as
wasted work, but the reality is that in many cases, there are few good
alternatives, because development of the prototype is essentially
development of the requirements and specifications.  There's feedback
between what's wanted - that vague idea in our heads - and what we can
actually produce with the resources available.

This relates directly to one of your action points:

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

I think the construction and the path are intertwined.  The features and
limits of the tools we use to do the construction will affect the path.

> Finally, for someone who isn't repeatedly challenging me to build
> things...

I've snipped all my quoted comments which were not directed specifically
at you, and will respond to the remaining ones.

>> What do you have in mind?

I didn't have a clue what you were thinking of, and so I asked for an
explanation.  Without that, I can't respond meaningfully.  However, I made
an attempt anyway - here's the original exchange:

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

I'm doing my best to respond to the points you're raising.

Next:

>> Those don't qualify as concrete suggestions.

This was in response to your points "5. walk; 6. run?".  I considered that
unconstructive.

My remaining comments were indeed directed at you:

>> you're not saying "I think we should do X", where X is
>> something *much* more specific and achievable
...
>> 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.
...
>> you don't offer some idea of what you see as
>> possible solutions, or what kind of solutions would satisfy you
>
> ...you certainly ask for concrete solutions frequently.

I'm mainly asking for some detail on what you have in mind on many of
these issues, because it just isn't clear to me.

So far, I've gathered that you think we should halt activity until we've
agreed on the "path [to] a published book".  Once again, I'm not sure how
to respond to this - I need to know more about what you have in mind. 
Otherwise, any response I give is likely to met with the sort of response
which you gave Noel:

> No, "use a wiki" is not a path. "use a wiki" is the construction
> method of the path. It says nothing about route or schedule.

I don't want to play guessing games.

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