Home

Project status meeting minutes (2008-03-13)

Thu, 03/13/2008 - 04:00 — dscott

Held at Mills Library, McMaster University

Present:

Anne Pottier, John Fink, Paul Otto, Cathy Maskel, Art Rhyno, Dan Scott

Status:

  1.  <1.5 people in total are working on the Conifer end of the project. Includes parts of Dan, Art and John but all have other on- going responsibilities which draw them away from the project.

  2.  Hardware for development platform: After problems with the Dell servers that were initially ordered these were returned and HP's were ordered from Audcomp last week. Delivery is expected this week, and invoices should be sent from Guelph to the Conifer institutions by the end of March to avoid budget cuts. In the interim Laurentian has made a test server available at
    http://biblio-dev.laurentian.ca/

  3. Reserves: Concept and requirements are in place but development work has not begun.

    • The native Evergreen academic reserves implementation (associate items with a given course, which would temporarily apply new circulation rules and location, and be retrievable via additional course code, course name, and instructor name attributes) would take approximately one week of infrastructure time and another week or two of user interface design and implementation.

    • Integration of the ReservesDirect (http://www.reservesdirect.org) open-source course reserves application is another option that would provide significantly more features (faculty can fax in reserve material), but would require the development of an OpenSRF client. It would also require internationalization work to be suitable for Laurentian, as it currently uses hard-coded English strings throughout.

    • Requirement: we want to ensure that reserve circulation statistics for items are kept separate from regular circulation statistics; we also want to be able to keep the circ stats for an item before it goes on reserve from being wiped out once it goes on reserve (a problem with current reserves systems).

  4. Acquisitions: Being worked on by Equinox. Basic level functionality is expected for end of April. An initial prototype is available now and we will be given access to test. Dan demoed some of the screens; the continually updated (and occasionally broken!) development version is visible at http://acq.open-ils.org/oils/acq/base/ Depending on the outcome of testing and refinements a more complete version (improved user interface, EDI support) should be ready this summer but there is no hard end date for a completed version as yet.

  5. Serials: Being worked on by Equinox. Bottom layer (database schema) is complete, but middle layer and user interface remain to be developed and tested. No predicted completion date at this point.

  6. Multilingual capabilities: Catalogue is 100% complete, including status strings. Staff client is approximately 60% complete (progress being roughly tracked at http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:customizations:i18n:staff_client_progress
    )

  7. Documentation: Some work is being done - a group of volunteer writers are receiving free training in exchange for documentation writing, and Dan is organizing the writing effort. A resource dedicated to documentation is needed, but the group's priority is to allocate resource to developing features.

  8. Training: More work is required to generate formal training materials. We hope to piggyback on some of the work being done in BC.

  9. Authentication: Evergreen's existing functionality will meet our current requirements. Neither McMaster or Windsor currently force patrons to authenticate their barcodes with passwords before being given the ability to renew items today. Laurentian does force patrons to use passwords, but their patron information is currently an entirely separate silo from the campus LDAP and registrar systems.

  10. Circulation - Loading of patron files being worked on by Conifer group. Migration of existing circ data for outstanding transactions needs to be addressed (Georgia PINES successfully migrated open transactions, so it can be done). For collection development purposes, we would like to migrate circulation counts for items - this might be harder.

  11. Cataloguing - The current loader for MARC records (an arcane set of commands) is inadequate and needs a user-friendly interface for bulk loading MARC records and holdings. Searching multiple Z39.50 sources at once is supported in the development version of Evergreen. Deletion of bibs inadequate.

  12. McMaster only - Endeca hooks into Evergreen need to be developed. Issues related to a single bib record shared database need investigation - one example, how do we best organize the 1 million records for which McMaster has a reciprocal sharing agreement so that McMaster patrons see this as part of their default search results but Windsor and Laurentian students don't?

  13. SRU/Z39.50 search - SRU ("Search Retrieval via URL" - the Web-based successor to Z39.50) server support has been implemented. Z39.50 server support will be a minor implementation detail on top of SRU. Testing with RACER is required but Dan doesn't expect it to be significantly different than today's RACER support; it should be possible to point RACER at a Z39.50 database representing an individual library org unit or group of library org units.

  14. Shared bibliographic records - the algorithms for detecting and merging duplicate bibliographic records into a single bibliographic record need to be tested. Paul has some (painful?) experience with this from his days at LAC.

  15. Reporting - Evergreen's reporting interface is extremely powerful, and will probably be overwhelming to the average user. However, Evergreen does enable you to build report templates that can be quickly customized. We will have to do the work to define a good set of report templates (not just for acquisitions, but for reporting statistics, etc).

  16. On- going operation - We need to decide how the operational infrastructure will be managed when we go into production:

  • Will we have one central site for the servers, with redundancy and lower latency provided by local servers containing local shards of the replicated data, or two or more geographically distributed server clusters?

  • Who is going to administer the Conifer application on a day-to-day basis (creating new circulation rules, responding to problem reports, assisting in data loads and reporting, etc)? Will we hire dedicated centralized resource for this, or distribute the workload between institutions, or some combination thereof?

Project timeline and issues:

  1. A reasonable target for implementation seems to be May 1, 2009. This matches our fiscal year-end, and will give us time for our staff to develop familiarity with the new system and update training materials for our patrons. It will also give enough time for the core development work required for our basic academic needs to be completed, along with load testing, practice bib record and patron data loads, policy discussions, etc. One site has switched their current ILS vendor contract to quarterly renewable payments to provide the most flexible options for cutting over to the new system.

  2. Additional resources from a successful grant application probably will not speed up the development work to the point that we can go live earlier. The assessment of the group is that there is a scarcity of capable people immediately available to do this type of development work and the process of finding them and getting them up to an efficient working level will be slow. Increased funding would have an impact on the end product which would be more robust, have better developed functionality and would provide more resources to insure a smooth migration and put in place an infrastructure which would allow for ongoing operation and be more able to accommodate expansion.

  3. If there is no large funding grant available it is thought that the addition of one or two developers along with current resources will be able to meet the May 1 date. To this end a contract developer job description is being written and Windsor will see if they can staff it (they are counting on some financial assistance from the other two institutions). It may be worthwhile for McMaster to also do this so we can test the market in the Toronto- Hamilton area in addition to the Windsor- Detroit area. If funding does become available we can use the job descriptions and postings but hire more people.

  4. Some small student-sized projects may be able to be funded through the Google Summer of Code (http://open-ils.org/dokuwiki/doku.php?id=advocacy:gsoc2008) or summer work positions. We'll hear back from the Google Summer of Code program on March 17th. Dan will apply for funding for at least one summer work position at Laurentian - they have a pool of students with Python work experience to draw from, and this could lead into an entry-level career position.

  5. If we receive funding the group would like to move Dan into a full time project management position and use the funding to cover hiring a temporary replacement for him at Laurentian. Dan now has a lot of contacts in the Evergreen world and a good knowledge of the project. Hiring another project manager would slow the project down.

Actions:

  1. A non- technical group will be set up at each institution to deal with issues related to developing further requirements, providing a testing resource, migration/modification of existing workflows and operating in a shared environment. Cathy and Anne will take the lead on this. Representatives of the local groups will meet with members from other institutions as required.

  2. Contract developer position to be written and posted (Dan, Art, John).

  3. Series of meetings for the steering group to be set- up for May, July, September (Paul).

  4. Grant Art Rhyno access to the Laurentian test server (Dan).

  5. Get a screen shot of Evergreen running in Chinese into Jeff's hands before he heads off to China (Art?)