In my view, I think the user and developer docs should contain facts and information about things that are, not proposals, goals, or forward looking statements, which might cause confusion. Would goals in the stable branch docs still be goals if they are not in the trunk docs?
The docs should match the code base for that branch. On 18/05/11 17:08, Jody Garnett wrote: > - A page describing the stated goals for the release (this amounts to our > roadmap) I think this should stay on the wiki. On the wiki, we can use Confluence/Jira integration to aid this. > - A page for each accepted proposal (I think we are stuck with the wiki for > this; as we want to be able to accept proposals from those with out commit > access?) Perhaps completed proposals should be moved to the manual, or at least documented in a migration guide? I would be reluctant to include unimplemented proposals in the manual. > - An "update to" page describing API changes made ( move to > welcome/geotools/udpate8 etc...) Yes! This should be in the user guide, or developer guide if we change tools (i.e Java 6, Maven 3). > - A page for each release (move to blog - as right now we are duplicating > effort) I think this might be worthwhile, if not too hard on the poor releaser. -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
