2020-08-07 Meeting notes

Minute taker

@Abigail Wickes 

Announcements/updates

• Product Council Meeting 2020-08-06

• PC did not meet 2020-07-30

• Product Council 8/6/20 update with testing from TAMU

  • A few hundred test cases & extensive analysis with multiple testers

  • Very comprehensive & helpful for distinguishing bugs from training issues

  • Slides/links for each test case w/ instructions, and Google form for feedback that fed into summary spreadsheet

  • Could be helpful model for local testing for other implementing institutions

  • Comment from Eric Harnett: “I think it’s more comprehensive because with the official bugfest, only one person looks at each case.”

Lehigh batch orders creation helper app

@Michelle Suranofsky

(Michelle Suranofsky, Developer; Lisa McColl, Cataloger)

Demo

• Importing records into OLE is a go live priority, so this is a temporary tool until functionality is available through FOLIO

• MARC records contain 980 fields; program is hardcoded to look for particular subfields (fund codes, vendor reference number, notes, print/electronic format etc.)

• Can handle multiple records in one file; example file with 6-7 records takes about 10 seconds

• Returns PO, HR ID, and Title; inserts approved PO (money is encumbered)

• Use property file to set up some info in advance, e.g. location

• Creates instance holding, item, MARC record; records can be edited in FOLIO

  • FOLIO creates based on subfield containing Instance set to True

  • Also performs validation on vendor, fund code before inserting info into FOLIO

  • All code is in FOLIO Labs GitHub repository under order-import-poc

  • Tested diacritics (challenging!)

Questions/Comments

• Q: Where did text from 980 field come from?

  • A: Local information for orders, can batch add many components using MarcEDIT; some vendors may be able to supply

  • Chicago has a few ways of adding; technical spec w/ vendor or for vendors who don’t have that capacity, manually entering from a spreadsheet then using MarcEDIT to create record from spreadsheet—seems faster and less prone to error than creating POs manually

  • Comment from Scott Perry—helpful for “orders in non-Roman scripts. It also leverages spreadsheets/lists from vendors so the metadata isn’t being keyed manually.”

Framework for documentation

@Marcia Borensztajn

(Marcia Borensztajn, Technical Writer for FOLIO Documentation) 

Overview

• Met with many stakeholders, identified wide range of needs; themes include

  • Need for personalization/need for generalization

  • Need for context (how do settings in one part of FOLIO impact other parts of FOLIO?)

  • Easy onboarding

  • Clarifying varying terminology

• Three pieces that need to happen: Technical Infrastructure, Process, and Content itself

• Technical Infrastructure

  • Dispersed through many sites and channels currently, so targeted, searchable documentation site will be helpful for end users

  • Tool Evaluation; GitHub already exists, can build onto it w/ static site generator (leaning towards Hugo) to present info as website

  • Potential to explore adding CMS (Netlify, Forestry…) on top for people to interact w/ UI, contribute to documentation, etc.

• Process—documentation needs to be part of the development process

  • Documentation should be part of dev team’s “definition of done”, part of testing process

  • Maintenance needs to be part of plan

  • Process of creating documentation also offers opportunities for assessment as details are captured, interrogated

• Content

  • Considering high-level structure/navigation, style conventions, what core apps need documentation to “go live”?

  • Phase 1 Road map—stand up a demo environment; testing using Git as repository for docs; draft high-level structure (TOC); draft initial topics for one app; explore potential style guides; explore options to externalize writing; review candidates for Google Season of Docs (currently matching, should know in mid-August; hoping for two writers)

  • Phase 2 Road map—work with marketing to create entry point; work with development to add Help icon, establish docs repository, enable association of specific releases with specific set of docs; work with SysOps to move demo site to prod, establish presence in JIRA; select first app to document, documentation development roles for that app

  • Phase 3 Road map—determine core set of apps to “go live”; keep refining content creation and maintenance process; develop contribution guidelines; provide high-level, introductory Installation Instructions for those getting started with FOLIO

Demo

• Left nav first pass categorization of varying apps—already getting feedback on structure; considering “laundry list” of apps vs. groupings (looking for more people interested in providing this feedback! Get in touch with Marcia!)

• Importance of having something to react to

• Localization options to include different language options

Questions/Comments

• Question about sustainability

  • Many use github as a place to hold code or site data, but are we thinking of a place to hold any of this site data, or at least a second location to hold a copy of this site data in order to rebuild it? (Storage is not preservation, lots of copies keeps stuff safe mindset)

    • Example of accidental deletion of Google Drive files

  • A: Preservation part of the reason for going with github from the first place; document preservation can fit in with what is already done for code. What are developers doing for preservation?

  • Not totally clear about current github archiving current practices; concern about github availability in the future (hypothetically)

  • Hopefully something Tech Council has considered

  • https://archiveprogram.github.com/

AOB

• Duke question about how other institutions are using fields when creating vendor records in Organizations; confusion in Vendor Information—are fields driving functionality or information?

  • Some of each

• Is Payment method field just supposed to be primary method used, is it informational?

  • Not driving functionality, just informational

  • Chicago not using that field (optional, not required)

• Expected Activation interval—is this for e-resources?

  • Yes (is it expected to take a day, two weeks, etc.?)

• Expected invoice interval

  • Anne-Marie checking whether this is how long NET terms are for payment or what

  • Maybe could be labeled a little more clearly if that’s the intention

• How to handle Claiming interval for orders with agents with many different publishers with different intervals?

  • Leave it blank

• Difference between Claiming Interval and Expected Receipt Interval?

  • Expected receipt could be shorter time period than claim interval for following up

  • Documentation says that field sets expected receipt time on PO line

• Difference between Expected Activation Interval vs. Renewal Activation Interval, in context of Renewals functionality that might not be planned for currently?

  • Wiki Documentation (https://folio-org.atlassian.net/wiki/display/RM/Acquisitions+Organization+Module) says sets default renewal interval on PO—still up to date?

    • Should be up to date; subscription interval is amount of time standard subscription from vendor should commonly last; renewal activation is supposed to be time before renewal end date for review (e.g. 60 days before; driving future dashboard functionality)

  • One EDI information section

    • Main EDI section is meant to be default, but there will sometimes be cases where individual accounts with vendor might need different EDI identifier (can be noted in Accounts section)

  • All these fields are optional, so you can leave things blank and determine how to use them later

  • Could add running agenda item for testing/implementation questions?

    • Duke would be happy to keep bringing these questions