| Item | Who | Notes |
|---|
| Minute taker | |
|
Announcements/updates |
| - 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, 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!)
- 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, 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
- 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?
- 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?
- 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
|