Re: Manual

[glen e. p. ropella]

> This reply was not addressed to me, but since it went to the group, I
> take that as an invitation for all of us to join in.

Definitely.  I'm not sure how others view the list...but, in 
my opinion, it's a public forum upon which anybody can say
anything they want.  Of course, given that it's intended to
address Swarm issues is obvious.  The "support" part is a bit
misleading because it implies the normal software support one
may get from a software company.  I'd like to *deprecate* that
usage of the list (where SFI is the hub of the support network)
and make it an all around transparent network.

As a matter of fact, I wouldn't even mind if someone outside
SFI wrote most of the manual.  Of course, we (the hive at SFI)
would like to peruse and help revise it.  And given what Sven
went through in taking some responsibility for a core code 
contribution, the manual writing process would be quite painful
for both ends.  (Plus, I'm not sure that the other 2/3 of the 
hive, here, would go for someone else writing the manual. [grin])

> May I suggest the following way to arrange a manual (if we are talking
> about one manual) ...
> 
> Part 1:  Introduction, via a sample application
[...]

A fundamental problem with this approach is the selection of
the example.  One of the reasons Swarm actually is an innovation
is because it handles such a broad set of applications that none
could really be considered canonical.

> Part 2:  Technical description
[...]
> Part 3:  Problems that have been approached with swarm
> 
> This could be a short description of various projects that are currently
> being tackled with swarm.  Each example would have a description of the
> question the researcher was asking, how and why swarm was used to
> address the problem, and information on how to get more information if
> you desire.  I'm sure there will be some excellent examples to choose
> from at the meeting.

Part 3 would help assuage the problem with example selection in 
part 1; but, it might still lack the explication of the "big
picture", so to speak.

> This is just a suggestion.  I think that this would be an excellent
> topic of discussion at the meeting.

I think this is a very useful suggestion.  However, I think
it lacks the higher level picture that would allow a given
user to extract the germane pieces of what swarm can do and
what's been done with swarm that apply cleanly and coherently
to their specific application.  So, maybe, if we added a part
in front of part 1 that tried to get this across before going
into the held up example.

glen