Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Comments

RequestsQ4
  • No one on the call had objections to putting requests at the end of the queue when moving from one item to another as long as they can be manually reordered and the request creation date is unchanged and visible
  • Just in case Chalmers really objected to this idea, we discussed the rush request alternative briefly as well
    • General sense was there would be cases where you would want to reorder a request but not do a rush request. 
    • More discussion is needed on use cases, but a couple were offered:
      • Someone is in position 2 of the queue calls and says, "I want to be in the queue, but will be out of town for a while, can you move me to the bottom"
      • Library requests an item for document delivery of a chapter of a book for the China campus.  They want it at the top of the queue but don't want to "rip it away" from the person who has it now.
    • Overall, SIG would prioritize manual reorder of the queue and think rush requests would be an additional  feature down the road
  • Carsten said he was still very interested in instance/title level requests which would reduce the need to move requests from one item to another.  Chalmers really wants this to.  We plan to start a subgroup to gather requirements on this topic, but it hasn't been flagged cap-mvp.
  • Carsten wondered what patrons would think if they saw their queue position changing.  Andrea and others on the call said it hasn't been an issue for them (and some institutions don't show queue position to patrons)






Notes