2021-01-22 Resource Management SIG Meeting

Product Council

• Technical Council update: elastic search encountering some challenges with licensing w/r/t Apache 2; technical council is investigating whether this impacts FOLIO–more updates in coming months
• Update on changes to QA process: concerns on length of release cycle, potential for too many bugs coming up at the end of the cycle in bug fest
  • Owen: earlier testing is great, but concentrated focus is beneficial; some concerns about effective use of SME time (spread out testing more time-consuming, could be many people testing the same things over and over again...) no surprise many bugs are uncovered during bug fest since that's the way it's designed, but would be open to more spread out testing if it works for SMEs
  • Eric H: "Time is the issue. We're already doing internal testing in addition to participating in bug fest. So this would be a third bug test."
  • Virginia: More testing sounds good in theory, but what institutions have capacity? (SMEs are already in hours and hours of FOLIO meetings each week)
  • Sara C: put in more than 1-2 hours of testing already–idea of additional 1-2 hours of testing weekly to spread out testing efforts seems like an underestimate
  • ACTION: clarify Anton's expectations as to whether bug fest time would be reduced
  • Sarah Dennis: would be happy to help with testing if needed
  • Owen: Anton is also pushing for automated regression testing; bug fest is intended to find small issues; shouldn't be using bug fest for User Acceptance Testing (UAT.) Challenge that sometimes people only realize how something works during bug fest, which should be avoided but can be tackled through UAT and communication via SIGs and small SME groups
  • Dennis: earlier testing is more focused on specific functionality, validating no requirements missed or misunderstood, and by way of that uncovering small things to fix; UAT takes a lot of time, but value comes from thinking about functionality in depth once it's in front of you
  • Considering developing a list of volunteers for focused early testing (not to replace UAT)
    • Virginia: question of whether testing is best use of people's capacity instead of other FOLIO work (e.g. working on documentation, which would probably lead to finding a few bugs...)
  • Kristin: to summarize–UAT testing is a good use of time; less convinced of utility of moving regression testing earlier in the process (people are feeling resources are already stretched) same amount of time spent developing documentation could have similar, more expansive benefits
  • Dennis: proposing giving RM SIG meeting time back to people during weeks of UAT
    • Virginia: or spending RM SIG time debriefing about UAT
    • ACTION: FY rollover UAT debrief on agenda for next week's meeting
    • ACTION: Join Acquisitions Slack channel if you are interested: #acquisitions-uat

ACTION: Everyone, please start adding to new RM Implementers Issues page!

Organizations and multiple roles

• How are people handling the vendor and non-vendor aspects?

• Duke currently has prefix of E to distinguish Organizations added manually before import for ERM purposes (used to store credentials, admin info, act as Licensor) not sure if they will be merged with vendors; additional challenge of multiple libraries at Duke
• Sara C: in Aleph, just vendors; in CORAL, more variety of organization types; challenge that some organizations are a vendor in one instance, content provider or platform in other instances... (tracking platform can be important since there can be platform-wide issues impacting multiple content providers)
• Jack M: Ingenta Connect example at UMass; CORAL came pre-populated with organization shell records, so migrated over to FOLIO; platform organizations mainly just for contacts, admin info; want to make information complete but understandable for non-acquisition colleagues who will be using this information, reporting
• Owen: Platform is complex area; currently two or three concepts of a platform; problem of Organization info not being available at Agreement Line level–could be helpful to bridge that gap; some organizations might continue just using ERM functionality without investing in Orders; want to become more flexible in making these connections w/out forcing creation of duplicate Organization records depending on how they are used
  • Jack M: CORAL did this fairly well since it didn't try to constrain anything, e.g. EBSCO record could have multiple options for organization roles, then could multi-select on resource records
  • Owen: if we could manage this in one place (Orgs) like we have the "Vendor" checkbox already, then we could potentially make it work
  • Eric H: another situation: I handle negotiations for TAMU System agreements so I have organization records in CORAL for each campus in the system with contact info, IPs, etc., all associated with TAMU System record through a child/parent relationship
    • Owen: child/parent is an important question–whether that's something Orgs should support, might help
• Kristin: order of implementation and what data you are working with informs a lot of these challenges
• Dennis: roles for Organizations put on pause because functionality would be different depending on different roles
  • Virginia: some UI issues with Organizations as well for adding contacts, interfaces
  • Alice D: agree with Sara C's concerns–brought this up at UA and keep ERM vendor contacts completely separate from Organization records which we use for payment only; Organization payment rarely changes, whereas URLs, rep contact changes frequently (already have admin info stored in password management system)
• ACTION: capture this discussion on new RM Implementers Issues page
  • Virginia: would be helpful to eventually be able to rank various features discussed in RM SIG calls
• ACTION: link unranked features to prominent place in RM Wiki