The Solano Napa and Partners (SNAP) Consortium have developed a functional requirements document that is available for you to use in your next ILS procurement.  The work was funded by an LSTA grant.

SNAP and library staff worked with Melissa Stockton (Quipu Group) and Lori Bowen Ayre (The Galecia Group) to develop the document through a series of focus groups that tackled the various functional areas of an ILS.

The document is designed for a consortium but could be fairly easily modified for use by stand-alone libraries.

An Open Doc version of SNAP's Requirements is attached to this post in case anyone would like to use it in their own procurement or ILS evaluation.

Owen Leonard provided a succinct and useful description of how new developments make their way into a final release. Here's my rendition of the process....

He began the story with "a patch is submitted" which means that your or your developer has figured out how to add the enhancement or fix the bug and the code has been made available to other developers to take a look at.  That code is "a patch."

Once the patch is available to others, it can be pulled into a live or (more likely) a test system so someone can test it.  Once someone tests it and verifies that that is indeed a useful and functional patch, they can "sign off" on that patch.  It is great to have more than one person "sign off" on a patch.  The patch cannot move to the next step until at least one person has signed off and changed the status of the patch to (predictably) "Signed Off."

After that, it is really up to the core development team to take the necessary steps to get that patch into the next release.

The QA manager (currently that person is Ian Walls, congratulations, Ian!) tests the "signed off" patch again and confirms that it works AND that the code meets project standards.  Only the QA Manager can get it past this step.  Once it is approved, its status become "Passed QA." 

Next, the Release Manager examines the patches that have "Passed QA" and assuming the RM also agrees that the patch is good, that patch is "pushed" which means it becomes part of the next release!

This post is copied from the Koha Mailing list.  It is the fabulous Ian Wall's response to a question someone had about what is involved in hosting one's own Koha server...

To host your own server, you'll need some level of comfort with Linux command line operations.  I recommend a Debian Squeeze server.  You can either purchase a new physical machine, or create a virtual server on an existing machine or in the cloud.  You can quickly fire up a server in the cloud using services like Amazon Web Computing, Rackspace or Linode.  This saves you from having to install an operating system on a piece of physical or virtual hardware.

Once you've got the server up and running, you'll need to install Koha.  You can do so from the packages, from the git repository or from the downloadable tarballs.  Personally, I recommend the git installation, but my understanding is that the packages are a little more user-friendly at the installation phase.  Are you going to be developing on Koha at all?  If so, then a git installation is definitely the way to go, so you can track your local changes, and format them in a way to submit back to Koha!

In addition to installing Koha itself, you'll need to install it's dependencies.  That includes MySQL (with which you said you were familiar), Zebra and Apache (Perl is almost always installed by default).  The installation instructions for Koha will walk you through those steps.  Further, if you want your Koha install to be able to send email notices, you'll want to install and configure an MTA (Message Transfer Agent).  I recommend Postfix, but exim4 also works.  The default SendMail also works, but I've found it a bit less flexible and thus a little more frustrating.

You'll also need to be comfortable with the crontab, so you can set up nightly jobs like fines, overdue notices, and backups.  This is one part syntax (knowing how to put an entry on crontab) and one part text editor familiarity (vi or nano, typically).

If all this seems a bit overwhelming, you're not alone.  If you need assistance, I'm sure there are Koha support companies in your geographic region who would be happy to assist you with installation, and may even provide hosting options.  Check http://koha-community.org/support/paid-support/ for a listing of known support companies from all over the world.

This just in via the Evergreen Mailling list (http://open-ils.org/listserv.php):

The Sitka team has produced four step-by-step videos on Evergreen Booking. Hosted by Jennifer Pringle, Sitka Trainer, the videos walk through Booking administration and general functionality for staff.

The videos are licensed CC-BY-SA 3.0 and are available here:
http://videos.cooperative.bclibraries.ca/

And there's more!  The Sitka team has also produced several videos about Reports and they are planning to do a series on Acquisitions!  Stay tuned.  

This came trhough on the Koha Mailing List and it looked so useful, I wanted to share it here.  It describes how to load MARC records into the Koha catalog for OverDrive e-books and audiobooks, etc so they are discoverable and show up in the catalog as non-holdable E-Resources avaiable for download.

Note, Brendan Gallagher of ByWater Solutions suggests that you use the "Stage MARC Rcords" option found under Tools (in Koha) so that you can batch remove these records (UNDO import into catalog) when it comes time to remove the OverDrive items from your catalog.

These step-by-step instructions come from Heather Braun of NEKLS (Thanks!):

Overview:  Develop a standard item record line for all of these and use MarcEdit to add this item record line to all the Overdrive records, THEN import them into Koha. 

The item record line I'd developed looked like this: 

=952  \\$bNEKLS$oeBook$d2010-12-30$zeBook from Project Gutenberg$8ERESOURCE$75$cADULT$yBOOK$aNEKLS

What we set up special for this was the ccode ($8) of Electronic resources (EResource) and the Not for Loan status ($7) of Download (which was set to be non-holdable). 

Also we gave them all the call number ($o) of eBook (or whatever the item was -- eAudiobook, etc.) and a public note ($z) explaining what the item was and where it was coming from. All of the records also had an 856$u that added a hyperlink to the location of the downloadable record. I'm assuming your records have this field and information.  

Using MarcEdit (http://people.oregonstate.edu/~reeset/marcedit/html/index.php): 

1. Load the MARC record file into the MarcEditor interface in MarcEdit. (You have to break the MARC file into readable format. See http://people.oregonstate.edu/~reeset/marcedit/tutorials/break_tut.ppt for instructions). 
2. Have your item record code line ready to be added and on the clipboard.   Like the following:    \\$bNEKLS$oeBook$d2010-12-30$zeBook from Project Gutenberg$8ERESOURCE$75$cADULT$yBOOK$aNEKLS
3. In MarcEditor, go to the Tools menu, Add/Delete Field.
4. In the Field dropdown menu, type 952 (Koha's item record field). 
5. For the field data, paste your field data. Example: \\$bNEKLS$oeBook$d2010-12-30$zeBook from Project Gutenberg$8ERESOURCE$75$cADULT$yBOOK$aNEKLS
6. Click Add field, and this 952 line will be added to all of your records in the file. 
7. You'll need to compile the file back into MARC format (File menu, Compile into Marc) and save it in MARC format, then load into Koha. 
8. That should do it!