[Geoserver-devel] The "GEOSDEV" documentation space

Hey all,

I cleaned up the GEOSDEV space a bit. But as I finished cleaning it up, I wanted to talk a bit about what we all think that this space is actually *for*.

My idea was that the GEOSDEV space would function a bit like the http://docs.codehaus.org/display/GEOTOOLS/Develop space. That is, it's a place for ongoing documentation, support, future planning and collaboration around the ACTIVE development of geoserver.

There's a page for each branch/version, and changes, updates and plans for that branch/version could go on that page. Like the geotools pages for 2.2.x, 2.3.x, 2.4.x, etc. It's like a much more detailed and active version of the Geoserver "Roadmap" that also lives in the GEOSDEV space.

I see the policy about what each space is for sort-of like this:

GEOS -- The main geoserver site. Place for downloads, blog, user or community-centric news, etc. A 'community space' as it were, where GSIPs (and other things like them) get hashed out by both developers *and* the community. GEOSDEV could probably live quite happily at GEOS/Develop (like in geotools). But hey, we've got the extra space, so why not use it.

GEOSDOC -- The hardcore documentation space. The official user-manual and official developer guides live here. The big question I had about the GEOSDOC space is "Which *VERSION* of geoserver does this documentation refer to?" And "which branch do these development practices apply to?"

I think the answer has to be "GEOSDOC is about *standard* development practices, and the User manual there is about the CURRENT geoserver release." I suppose this means that documentation that is out of date or no longer relevant to a current version should get deleted from GEOSDOC. What about previous version support though? That's a tough one, but I suppose we could just export the site as a part of each major version release.

Note that corollary of the previous paragraph is that there shouldn't be any version numbers in the Users Guide part of GeoServer. And for the developers guide part, those bits that are specific to a particular version should clearly state so.

GEOSDEV -- I see this as the place where the developers have their wiki space. To expose new ideas, plans, diagrams and stuff. Things that aren't GSIPs, and that don't fit cleanly into GEOSDOC (hey, they may never make it to anything at all anyway!) but that aren't exactly community-focused discussion either.

What do other people think about this? As I said, Geotools does this with just two spaces--GEOT, which has community and a special (big!) section for developers and GEOTDOC, which is the user manual. Whatever we decide, I think there's a need for all three sections, and wherever the right place is for each one, we should prominently note this.

--saul

Afternoon Saul :slight_smile:

I cleaned up the GEOSDEV space a bit. But as I finished cleaning it up, I wanted to talk a bit about what we all think that this space is actually *for*.
  

Thanks!

My idea was that the GEOSDEV space would function a bit like the http://docs.codehaus.org/display/GEOTOOLS/Develop space. That is, it's a place for ongoing documentation, support, future planning and collaboration around the ACTIVE development of geoserver.
  

My original plan was to use this space as a "staging area" for documentation on community modules that are not yet included in the GeoServer release. I wanted a space to clean up the developers guide instructions for GeoServer 1.4.0 (and we were not allowed to wreck what was being used for the GeoServer 1.3.0 space).

Basically some wiki space where we could "get things ready" .. basically documentation for "trunk".

There's a page for each branch/version, and changes, updates and plans for that branch/version could go on that page. Like the geotools pages for 2.2.x, 2.3.x, 2.4.x, etc. It's like a much more detailed and active version of the Geoserver "Roadmap" that also lives in the GEOSDEV space.
  

Sweet.

I see the policy about what each space is for sort-of like this:

GEOS -- The main geoserver site. Place for downloads, blog, user or community-centric news, etc. A 'community space' as it were, where GSIPs (and other things like them) get hashed out by both developers *and* the community. GEOSDEV could probably live quite happily at GEOS/Develop (like in geotools). But hey, we've got the extra space, so why not use it.
  

I quickly got lost in the GEOS space - you are correct we could use it as an "ideas" space ... like in geotools.

GEOSDOC -- The hardcore documentation space. The official user-manual and official developer guides live here. The big question I had about the GEOSDOC space is "Which *VERSION* of geoserver does this documentation refer to?" And "which branch do these development practices apply to?"
  

It should refer to the *current stable* version! We should export out this documentation in html form and make it available as a separate download for each stable release.

When we have a "new feature" the existing documentation can be copied from GEOSDEV to GEOSDOC :slight_smile:

I think the answer has to be "GEOSDOC is about *standard* development practices, and the User manual there is about the CURRENT geoserver release." I suppose this means that documentation that is out of date or no longer relevant to a current version should get deleted from GEOSDOC. What about previous version support though? That's a tough one, but I suppose we could just export the site as a part of each major version release.
  

You reached the same conclusion I did.

Note that corollary of the previous paragraph is that there shouldn't be any version numbers in the Users Guide part of GeoServer. And for the developers guide part, those bits that are specific to a particular version should clearly state so.

GEOSDEV -- I see this as the place where the developers have their wiki space. To expose new ideas, plans, diagrams and stuff. Things that aren't GSIPs, and that don't fit cleanly into GEOSDOC (hey, they may never make it to anything at all anyway!) but that aren't exactly community-focused discussion either.
  

Question - where should formal design documents live? I would like to get them ready in GEODEV ... and then copy them to GEOSDOC when the GSIP is accepted.

What do other people think about this? As I said, Geotools does this with just two spaces--GEOT, which has community and a special (big!) section for developers and GEOTDOC, which is the user manual. Whatever we decide, I think there's a need for all three sections, and wherever the right place is for each one, we should prominently note this.
  

Here is a possible breakdown that may be easier to understand:
- GEOT - community & planning
- GEOSDOC - official user documentation shipped with each release
- GEOSDEV - official developers documentation shipped with each release

(that is just an idea you may hate it - actually I might even hate it)

The last tip is to use confluence to our advantage:
- parent/child for table of contents
- make use of tags more often, tag design pages according to version number
- tag documentation pages that need to be reviewed before release etc...

Jody,

See response inline (thanks for the quick response!):

My original plan was to use this space as a "staging area" for
documentation on community modules that are not yet included in the
GeoServer release. I wanted a space to clean up the developers guide
instructions for GeoServer 1.4.0 (and we were not allowed to wreck what
was being used for the GeoServer 1.3.0 space).

Great idea. That's exactly what I think it should be used for.

You reached the same conclusion I did.

Fools seldom differ. I think there's a nicer version of that one, too.

Question - where should formal design documents live? I would like to
get them ready in GEODEV ... and then copy them to GEOSDOC when the GSIP
is accepted.

I think that GSIPs (and their formal design documentation) could live in GEOS just fine.

Here is a possible breakdown that may be easier to understand:
- GEOT - community & planning
- GEOSDOC - official user documentation shipped with each release
- GEOSDEV - official developers documentation shipped with each release

(that is just an idea you may hate it - actually I might even hate it)

Yeah...I like that GEOSDOC is more 'official' than GEOSDEV. Sometimes it can be hard (and would be DAUNTING if I was just starting with geotools) to go through GEOTOOLS/Develop, and I think that GEOSDEV will quickly become a place where the ideas of geoserver development live. The official developers guide (on GEOSDOC) should definitely refer to GEOSDEV as the 'current brainstem of geoserver' or something. But I think there should be a much more static GEOSDOC-based developers guide.

Version-matched documentation is still a problem though.

The last tip is to use confluence to our advantage:
- parent/child for table of contents
- make use of tags more often, tag design pages according to version number
- tag documentation pages that need to be reviewed before release etc...

Good ideas. I don't use tags enough.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

regardless of whether they are the sam espace or not, we need to keep clean copies of automated docs per release IMHO, since we'll never keep it up to date otherwise.

I think the user documentation should be included in the official release docs, and GEOS should link to the current stable release.

GEOSDOC/<branch> for official release docs for each supported branch (and remove old versions from each branch)

GEOSDEV could be where design stuff happens.

Do we need to put emerging stuff in GEOSDEV if its part of the release and put in the release cycle?

One nifty idea my be to mark up (automatically) each piece of doc with the release version it was _last modified_, so if behaviour has changed there is a clue if the doc is up to date or not.

Rob

Jody Garnett wrote:

Afternoon Saul :slight_smile:
  

I cleaned up the GEOSDEV space a bit. But as I finished cleaning it up, I wanted to talk a bit about what we all think that this space is actually *for*.
  

Thanks!
  

My idea was that the GEOSDEV space would function a bit like the http://docs.codehaus.org/display/GEOTOOLS/Develop space. That is, it's a place for ongoing documentation, support, future planning and collaboration around the ACTIVE development of geoserver.
  

My original plan was to use this space as a "staging area" for documentation on community modules that are not yet included in the GeoServer release. I wanted a space to clean up the developers guide instructions for GeoServer 1.4.0 (and we were not allowed to wreck what was being used for the GeoServer 1.3.0 space).

Basically some wiki space where we could "get things ready" .. basically documentation for "trunk".
  

There's a page for each branch/version, and changes, updates and plans for that branch/version could go on that page. Like the geotools pages for 2.2.x, 2.3.x, 2.4.x, etc. It's like a much more detailed and active version of the Geoserver "Roadmap" that also lives in the GEOSDEV space.
  

Sweet.
  

I see the policy about what each space is for sort-of like this:

GEOS -- The main geoserver site. Place for downloads, blog, user or community-centric news, etc. A 'community space' as it were, where GSIPs (and other things like them) get hashed out by both developers *and* the community. GEOSDEV could probably live quite happily at GEOS/Develop (like in geotools). But hey, we've got the extra space, so why not use it.
  

I quickly got lost in the GEOS space - you are correct we could use it as an "ideas" space ... like in geotools.
  

GEOSDOC -- The hardcore documentation space. The official user-manual and official developer guides live here. The big question I had about the GEOSDOC space is "Which *VERSION* of geoserver does this documentation refer to?" And "which branch do these development practices apply to?"
  

It should refer to the *current stable* version! We should export out this documentation in html form and make it available as a separate download for each stable release.

When we have a "new feature" the existing documentation can be copied from GEOSDEV to GEOSDOC :slight_smile:
  

I think the answer has to be "GEOSDOC is about *standard* development practices, and the User manual there is about the CURRENT geoserver release." I suppose this means that documentation that is out of date or no longer relevant to a current version should get deleted from GEOSDOC. What about previous version support though? That's a tough one, but I suppose we could just export the site as a part of each major version release.
  

You reached the same conclusion I did.
  

Note that corollary of the previous paragraph is that there shouldn't be any version numbers in the Users Guide part of GeoServer. And for the developers guide part, those bits that are specific to a particular version should clearly state so.

GEOSDEV -- I see this as the place where the developers have their wiki space. To expose new ideas, plans, diagrams and stuff. Things that aren't GSIPs, and that don't fit cleanly into GEOSDOC (hey, they may never make it to anything at all anyway!) but that aren't exactly community-focused discussion either.
  

Question - where should formal design documents live? I would like to get them ready in GEODEV ... and then copy them to GEOSDOC when the GSIP is accepted.
  

What do other people think about this? As I said, Geotools does this with just two spaces--GEOT, which has community and a special (big!) section for developers and GEOTDOC, which is the user manual. Whatever we decide, I think there's a need for all three sections, and wherever the right place is for each one, we should prominently note this.
  

Here is a possible breakdown that may be easier to understand:
- GEOT - community & planning
- GEOSDOC - official user documentation shipped with each release
- GEOSDEV - official developers documentation shipped with each release

(that is just an idea you may hate it - actually I might even hate it)

The last tip is to use confluence to our advantage:
- parent/child for table of contents
- make use of tags more often, tag design pages according to version number
- tag documentation pages that need to be reviewed before release etc...

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

Farber, Saul (ENV) ha scritto:

You reached the same conclusion I did.

Fools seldom differ. I think there's a nicer version of that one, too.

Great minds think alike :-p
Cheers
Andrea

Rob Atkinson ha scritto:

regardless of whether they are the sam espace or not, we need to keep clean copies of automated docs per release IMHO, since we'll never keep it up to date otherwise.

I think the user documentation should be included in the official release docs, and GEOS should link to the current stable release.

GEOSDOC/<branch> for official release docs for each supported branch (and remove old versions from each branch)

It would be nice indeed to have such a functionality.
There are some issues open against Confluence about this topic:
* http://jira.atlassian.com/browse/CONF-2814
* http://jira.atlassian.com/browse/CONF-3191
* http://jira.atlassian.com/browse/CONF-5970

Well, it seems some limited copy is already available in some
version of Confluence (not sure which...)
Anyways, if it's there, it does not seems I have the required
rights, that is, I don't see a copy functionality anywhere.

Cheers
Andrea