[OPEN-ILS-DOCUMENTATION] ACQ and Reporting documentation

[Karen G. Schneider]

Some of this has been discussed on the PINES lists, but this is broader 
than PINES. This is a proposed change in tactic for documentation 
intended to work better for everyone.

Initially the idea (as I understand it from former list traffic and 
discussion with some key folk) was that people in the field would be 
trained and documentation would flow organically from the field. In 
practice, though there are some excellent documents out there (and more 
about those in a minute), the training never was fully realized, and the 
would-be documentation writers were often too tasked with their primary 
work duties (and as a working librarian, I can fully 
relate--particularly in this crazy budget climate) that documentation 
didn't flow organically anywhere.

In retrospect, this isn't surprising and it's also not anyone's "fault." 
The original volunteers were troopers to raise their hands, and it was a 
great idea that simply ran up against real-world realities.

Meanwhile, GPLS/PINES have grant funding specific to writing 
documentation for Evergreen reporting and acquisitions -- which is a 
wonderful thing that will benefit the entire Evergreen community. We at 
Equinox are reviewing writing samples, searching for contract workers, 
etc. This work needs to happen before January. If you have names to 
consider, please email me at kgs at esilibrary.com.

We all know the best documentation when it doesn't happen in a vacuum 
and has a lot of real-world input. So in thinking about what the 
documentation community could do, I came up with these ideas. How does 
this sound? What do you think? What would you add?

   1. Some libraries have developed excellent local documentation. This
      will be very helpful material for documentation writers to work
      with. Sharing these would be valuable. Do we want to include local
      examples directly on the documentation wiki?
   2. To paraphrase Justice Potter, many of you on this list know good
      documentation when you see it. Your feedback and input are
      exceptionally valuable. You can be the "many eyes" for open source
      documentation. Your thoughts?
   3. Keeping the documentation in wiki format ensures that if you see
      an area for improvement, and you have wiki access, you can make it
      happen. Or you can share here on the list and someone with access
      can make it happen. Would this work?
   4. Much key development for Evergreen has happened because libraries
      funded it or contributed labor toward it. My own initial thought
      is that in the future, documentation should be part of
      development--funded, contributed, however--and should roll out
      hand-in-hand or at least closely after the actual software
      releases. What do you think?

-- 
| Karen G. Schneider
| Community Librarian
| Equinox Software Inc. "The Evergreen Experts"
| Toll-free: 1.877.Open.ILS (1.877.673.6457) x712
| E-Mail/AIM: kgs at esilibrary.com
| Web: http://www.esilibrary.com