[postgis-devel] [WKT Raster] Documentation on the WKT Rastertype

[Pierre Racine]

>In my personal opinion, that's the purpose of Wiki, to brainstorm,
>discuss and collaborate in editing.

But if I put it in the wiki then you won't be able to pin-point
sentences with comments. Only changes. I was thinking you could first
comment, then I would made some changes myself and then put them in the
wiki. The wiki will be the official documentation so it is not a place
to comment. Only to make changes. But I can put it in the wiki if you
prefer. (Unless you are religiously reluctant to Word documents.)

>By the way, after the recent re-(loss-of)-structure of specifications,
>I've clearly got lost in between N versions of the same documents
>dangling on the Wiki.
>I don't have time to copy and paste, for instance gdal2wktraster usage,
>between specification 01, 02, 03, etc.

There is only two documents now: Working spec and final spec. You should
copy the text in the final spec only once when everybody is happy with
the working spec. You certainly do not have to copy everything to the
next version specs.

>In my humble opinion, steps of valid process are:

>0. Brainstorm as "plan"

This is the purpose of 1) the mailing list and 2) the planification
page.

>1. Create document 1.0

This is the purpose of the Working specification.

>2. Collaborate editing document 1.0

This is also the purpose of the Working specification.

>2.1. Decide what goes from "plan" to 1.0 and put it there.

This is the purpose of the Final specification.
 
>2.2. All the rest is suspended in "plan" - document that's *not*
maintained while editing 1.0

This is also the purpose of the Working specification. If it does not
make it to the final spec then we can report it to the next Working
specification (0.2.4) for the next release.

>3. Approved and release 1.0

This is the purpose of the Final specification (and of the
documentation). 

We agreed on all this when we moved the wiki. I don't see why we are not
happy today.

I understand that this is not the way GDAL used to work but there are
other ways to work. I think this way makes specs available to everybody
(not only to those who have the code and can commit) and it ensure that
we keep track (history) of every addition and change. But we can change
all this if you wish.

Pierre