pcplantdb

[John Schinnerer <john@eco-living.net>]

Aloha,

> components:
> 1. technical spec
> 2. someone to write it
>
> For 1., we need a suitable tool.  AFAIK, options include:
> i. wiki (easy to use/manage/contribute to)
> ii. CVS (apparently more complicated)
> iii. something else?

A CVS is a system for managing files, not a document creation system.

My suggestion was that we use a CVS to manage our spec documents.

> So I suggest we go with i. unless someone has a better idea.

IMO spec documents should be cross-platform word processor and/or 
spreadsheet documents.

> what is the final format of our speec?  An .rtf doc?  A wiki page?  An 
> excel sheet?

We will probably have several different specs, including but not limited to:

Functional spec for database engine and its API.
Schema/DB design spec for database itself.
Functional spec for initial client, including UI and so on.
XML DTD for our XML markup for data transport.

Also, there is the project timeline document, which I think would be 
best/easiest as a spreadsheet.

> Should it be printable/interactive/otherwise?

If it's a cross-platform doc, it will be printable.
If it's stored in a CVS, it will be interactive in that different people 
can work on it without losing/stomping on others' changes.

> And, if 
> necessary, how/who will translate the spec from the creative format (i.e. 
> wiki) to the final (i.e. .rft doc)?

As long as we don't use a wiki for specs and project docs this is not an 
issue.
I STRONGLY recommend we don't use a wiki for formal specs and docs.

Let's get project space on an open-source CVS, which we will need for 
project code and data files *anyhow*, and use it for our spec and 
project docs (including plan, timeline, reports to grantors, etc.) as well.

Bite that one bullet now and get it over with.
Avoid yet more work reformatting/translating/trying to decide what to 
do/etc. down the road.

I don't have time or enough savvy with CVS systems to set this up.
I would be a "user" level person myself once the CVS is available and we 
have docs to work on.

> Our need: to communicate effectively (please elaborate on what your 
> communication needs are as you see them).
>
> Options include:
> i. listserv

Seems OK for most all except handling our project documents.

> iii. IM

Poor accessibility for me.
Time zone issues for a few of us far-flung folks.

> iv. one-to-one phone calls

If useful, just do it.

> v. conference call

Might be useful for specific topics/issues

> vi. discussion forums (i.e. ThinkCycle) - comparable to wiki?

Yet more software to install/set up/learn to use.
I suggest we avoid adding any more learning curves that are not 
absolutely necessary.

> vii. telepathy
> viii. communication via the dreamworld

Seldom effective for projects of this nature ;-)

> iv. other ideas?

Carrier pigeon?

Mail schooner?
I think you covered it pretty well... :-)

> Finally, discussions I'd like to introduce to the PIW list:
> -market-farming/SARE discussion
> -Rich's wikipedia/security model 
>
> Or should I wait?

Whatever...

John S.


--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net