[OPEN-ILS-DOCUMENTATION] Documentation Hackfest & Going Forward

[Soulliere, Robert]

Thanks Dan and Jason,

During the DIG meeting I volunteered to commit the documentation to the repository, so if I could be granted access that would be great. Let me know if you need more information from me such as preferred username. It would be great to have about 3-4 DIG repository committers if possible and to assign the committers specific parts of the documentation perhaps?

The suggestions to have the documentation in the same tree as the code makes the most sense to me for the purposes of documentation bug fixing and content sensitive documentation linking, etc...

The other important idea from the DIG meeting was the use of a cron job to process the DocBook documents into PDF and HTML files on a nightly basis so that online and downloadable documentation is as up to date as possible. Would that also factor into our repository decision?

Thanks,
Robert




-----Original Message-----
From: open-ils-documentation-bounces at list.georgialibraries.org [mailto:open-ils-documentation-bounces at list.georgialibraries.org] On Behalf Of Jason Etheridge
Sent: Wednesday, April 28, 2010 9:41 AM
To: Documentation discussion for Evergreen software
Subject: Re: [OPEN-ILS-DOCUMENTATION] Documentation Hackfest & Going Forward

> There is a subversion (SVN) repository for documentation currently at:
> http://svn.open-ils.org/trac/ILS/browser/trunk/docs/1.6.
>
> This seemed to be the intended repository folder for the Book of Evergreen at some point based on the existence of sample documents on that folder. However, I am not aware of any DIG people who currently have commit access to that repository. If that is the final destination for the documentation either someone on the DIG needs commit access to that repository or all documents will have to be committed by someone with access to that repository.

Hi guys, I don't believe it'd be a problem to grant commit access to
the Subversion repository to whichever people the DIG community
designates.  One advantage to putting documentation into the same
source tree as Evergreen is that it automatically ties the Evergreen
version with the documentation version.  If we cut a bug-fix release
for an older stable branch, its bundled documentation won't include
features that it doesn't have, etc.  I believe this was discussed in
the past but I can't find reference to it at the moment.

Something else worth pointing out is that in trunk, the staff client
has a context sensitive help widget now, based mostly on the URL of
the interface containing the widget.  See
http://svn.open-ils.org/trac/ILS/changeset/16228

To keep documentation all in one place, we may want to change where
that help widget looks for its content, or we could use indirection
and the help files that it loads could reference content from a more
centralized location.  The help widget is another good reason to have
at least the context sensitive documentation in the same repository.

--
Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  jason at esilibrary.com
 | web:  http://www.esilibrary.com

Please join us for the Evergreen 2010 International Conference!
It is being held April 20 - 23, 2010 at the Amway Grand Hotel and
Convention Center, Grand Rapids, Michigan.
http://www.evergreen2010.org/
_______________________________________________
OPEN-ILS-DOCUMENTATION mailing list
OPEN-ILS-DOCUMENTATION at list.georgialibraries.org
http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message.  If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited.  If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.