[OPEN-ILS-GENERAL] Looking for a way to plug-in?
We want you! The Evergreen Communication Committee needs more people to get involved and help guide the direction of our work going forward. When the Communication Committee was created two years ago, our mandate was to identify existing information, communication, collaboration and community resources and provide guidelines to the community about how to organize these resources to make it easier for community members to find and use them. This committee launched a Web Team task force for focusing on improving the existing Evergreen website and to plan a larger web-based framework for the growing Evergreen community. Well, we've done all that but there's more to do. Like, do we want to build out that web-based framework we designed based on what we learned the community needs? Or do we want to continue to make incremental changes? What else can we do to make communication clearer? Are there policies we need to develop? Join us for a meeting of the Communications Committee / Web Team on Wednesday at 10:30-Noon in Regency C for a discussion about how to move our activities forward. Or just stop in to meet some great people who've put their heart and soul into improving Evergreen and making the community stronger. We hope to see you on Wednesday at the Conference, 10:30-Noon in Regency C to help us plan for the coming year and determine how the Web and Communications groups can contribute most effectively! Lori Ayre (on behalf of the Communications Committee/Web Team) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-= Lori Bowen Ayre // Library Technology Consultant / The Galecia Group Oversight Board Communications Committee / Evergreen (707) 763-6869 // lori.a...@galecia.com Availability: http://tungle.me/lori.ayre lori.a...@galecia.comSpecializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[OPEN-ILS-GENERAL] Participation Guidelines for Evergreen Communication Channels
This message brought to you by the Communications Committee to help you navigate the world of Evergreen more easily... Ask *questions of general interest* to the community or to a specific group on one of the Evergreen mailing listshttp://www.evergreen-ils.org/listserv.php . *If your question is more specific*, like “I’m installing this and I have a particular error message,” try asking your question on the IRC channelhttp://www.evergreen-ils.org/irc.php. Always make a point of reporting back to the mailing lists when you've gotten answers to your questions off-list. The IRC channel http://www.evergreen-ils.org/irc.php is a synchronous channel where people are logged in and available for asking questions. Sometimes the channel is very quiet. Other times it is very busy like when a *community meeting* is being held. If there’s a community meeting in progress, please refrain from comments unrelated to the meeting topic at hand until the meeting is over. Add *events of general interest to the community* on the Evergreen calendarhttp://www.evergreen-ils.org/dokuwiki/doku.php?id=calendar:start, especially any meetings that are going to use the IRC channel. *Propose ideas and ask for feedback* on one of the Evergreen mailing listshttp://www.evergreen-ils.org/listserv.php. Some proposals may ask for feedback by a certain date, and if there’s no objections, the proposedsolution will move forward. Use the general mailing list http://www.evergreen-ils.org/listserv.php to *announce events* of general interest to the community or to the group that subscribes to the list. If there’s more of a story consider a blog postinghttp://evergreen-ils.org/blog/. Or, you may participate in one of the Evergreen related blogs that are aggregated at Planet Evergreen http://planet.evergreen-ils.org/. Or, start your own blog! Use the Evergreen Launchpad https://bugs.launchpad.net/evergreen to search for and post new *bugs*. Use Launchpad's search feature to see if the bug you wish to report already exists. If it doesn't, report it! Post information about *committees and working groups* meeting notes and other working documents on the Wikihttp://www.evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_committees Use the Evergreen Wikihttp://www.evergreen-ils.org/dokuwiki/doku.php#documentation to post *member contributed documentation* of all kinds Use the Evergreen mailing lists http://www.evergreen-ils.org/listserv.php to share *details about a development project* you are pursuing or to provide updates on a development project in progress.
[OPEN-ILS-GENERAL] Fulfillment Prioritization
There is a desire for copies to fill local holds before going into transit, even when there are already copies in transit. This would result in copies showing up to fill holds that are already filled, but would also allow for holds to go to the hold shelf faster when a copy is already right there. I have worked out the following thoughts for this, but would like more opinions before work is started on it. The general idea would be to add a new Org Unit setting to control the behavior. When enabled copies returned to the library would: 1 - Look for non-captured holds at the current location. If any exist, capture for them and move on to the hold shelf. 2 - Look for captured but in transit holds at the current location. If any exist, hijack that hold and move on to the hold shelf. The original copy will remain in transit. 3 - Resume all other holds/transit/reshelving/etc code normally. This may require teaching the hold targeter to update the list of copies *without* wiping the captured state of in-transit holds, perhaps with a special parameter passed in. That parameter may be best supplied when doing the Retarget Local Holds checkin modifier work, rather than as part of normal hold targeting. Especially if the first additional limitation below is included. I am thinking that there may need to be additional limitations, for sanity purposes, but am not sure about them: 1 - Limit to copies owned by the library that the checkin is happening at. This would basically prioritize local copies as filling local holds, but would not prevent someone else's copy from transiting. That transit may even be back to their own library. 2 - Not run the code if capturing local holds as transits. Because otherwise you may just be displacing things that are intentionally in a limbo-transit state. 3 - Require a checkin modifier be active, which may remove the need for YAOUS. If replacing the YAOUS then this would allow for per-workstation decisions. If alongside the YAOUS then the YAOUS being disabled could be used to hide the checkin modifier outright. Either way SIP may need to be taught how to (optionally) enable this modifier. 4 - In the event of a Force or Recall hold being in the stack, *never* fill a different hold instead. These are copy level force cut in line because we have a really good reason holds in Master/2.2, and I don't think we should avoid transiting to fill them. Thomas Berezansky Merrimack Valley Library Consortium
