Inline ....
On Mon, Oct 4, 2010 at 2:09 PM, Tim Donohue <[email protected]> wrote:
> Hi Stuart & all,
>
> On 10/4/2010 2:54 PM, Stuart Lewis wrote:
> >
> > On 5/10/2010, at 6:29 AM, Mark Diggory wrote:
> >
> >> On Sat, Oct 2, 2010 at 12:20 PM,<[email protected]> wrote:
> >> Author: stuartlewis
> >>
> >> dspace/trunk/dspace/docs/confluence/jspui.txt
> >> dspace/trunk/dspace/docs/docbook/jspui.xml
> >> dspace/trunk/dspace/docs/html/ch06.html
> >>
> >>
> >> Note, we definitly want to not be updating the existing docs in the svn
> and instead placing update in the confluence wiki, these
> dspace/trunk/dspace/docs files should be removed.
> >
> > Where in the wiki should these go, and how do we manage the versioning
> aspect: I can't add these updates yet, as they apply to an un-released
> version of the software.
>
> (Copying in Jeff Trimble & Peter Dietz, to make sure they are following
> this thread)
>
> Documentation changes for 1.7.0 should go on the wiki here:
> https://wiki.duraspace.org/display/DSDOC/DSpace+Documentation
>
> (This area is unadvertised to the general public, and is officially for
> upcoming 1.7.0 release.)
>
> As of 1.7.0, the [dspace-src]/dspace/docs/ folder should likely become
> obsolete, unless we wanted to archive a static version of the
> wiki-generated docs there.
>
Think it should just be removed completely to avoid confusion. a PDF
version should be distributed with each new release or at leat a README with
a link to the latest docs (see below)
> As for future versioning -- we really need to formalize this based on
> what we all feel is best. One possible option may be as follows:
>
> (1) "DSDOC" space
> (https://wiki.duraspace.org/display/DSDOC/DSpace+Documentation) -- this
> would be the place were we are *always* working on the latest & greatest
> documentation. It could also act as a "splash page" to find all past
> DSpace release documentation. So, currently this is working towards
> 1.7.0 documentation. We should also be working to "clean up" the front
> page and all sub-pages to our liking for 1.7 (It may still need quite a
> bit of work.)
>
> (2) When 1.7.0 is released, we can export an HTML or PDF version of that
> documentation directly from the "DSDOC" area. We could even put this
> into SVN if we wished, or just make it downloadable alongside the release.
>
I'm all for a readme with an http link to a version specific page in the
Docs wiki. It would contain links to the static html version, pdf version
and a link describing where to make suggestions for corrections,
recommendations and/or additions.
> (3) After 1.7, and once we are ready to start docs for a 1.8.0 release,
> we'll copy the "DSDOC" space into a "DSDOC1.7" wiki space as an archive
> (and as necessary to support any future 1.7.x releases), and the "DSDOC"
> area would move towards 1.8.0 docs. At this point, there may be some
> double wiki changes required if a single Documentation change needs
> fixing in both 1.7.x and the 1.8.x documentation (since they will sit
> separately in the Wiki).
>
I think this gets quickly becomes too complex. Recommend static publication
of docs a release time that does not change, pointer to the latest bleeding
edge docs in wiki if folks want to add read about whats new. As described
above.
(4) Eventually (i.e. years from now) in order to avoid keeping around
> tons of old wiki spaces (e.g. DSDOC1.7, DSDOC1.8, DSDOC1.9, DSDOC2.0,
> etc) for really old documentation, we'll want to clean up old "archived"
> wiki documentation. So, once a space becomes "dormant" or "static", we
> can just archive a final version to HTML/PDF and post that static
> version up on the DSpace website. Then we can remove that old, dormant
> wiki space altogether.
>
My concern is that this creates the overhead you talk about above, rather
than getting everyone "rallying" around one location for changes to docs.
This is just one possible idea for how to handle things. So, if there
> are other thoughts on upcoming management of Wiki Documentation after
> 1.7, we can definitely add that to an upcoming meeting agenda as needed.
>
> Thoughts/ideas welcome,
>
Thanks, Tim, for the great summarization on the topic.
Mark
--
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security
easier or more difficult to achieve? Read this whitepaper to separate the
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
