Date
...
Kristin Martin Cheryl Malmborg Hkaplanian (OLD ACCOUNT) Erin Nettifee Aaron Trehub Anya Boaz Nadav Manes Charlotte Whitt Gang Zhou Gar Sydnor Ian Walls Jana Freytag Karen Newbery Maura Byrne Owen Stephens Paul Moeller Philip Schreur Sharon Wiles-Young Stephanie Buck Thomas Risse twliu Brooks Travis Peter Murray Christopher Spalding Aaron Trehub Kirstin Kemner-Heek
Goals
Discussion items
| Time | Item | Who | Notes | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 5 min | Announcements | Kristin Martin | August meeting reminders
| ||||||||||||||||||||||||
| 1 min | Bug Fest | Bug fest is still not finished: test cases
| |||||||||||||||||||||||||
| 30 min | Managing functionality not yet built: Example of the User Profile Picture There is a feature that has not been fully developed - User Profile Pictures. It had been planned from the very beginning of FOLIO (
Questions:
| User management decided at its meeting yesterday to hide the setting for turning on the profile picture setting (resolving the immediate concern). There is nothing in the user record schema to hold photo information. There are other examples, however, of functionality that is incomplete. (There have been things in ERM and in Acq that are placeholders for future features.) This is of particular concern for the documentation; the style guide for the documentation says to not include information that will be in future releases. ("Avoid trying to document future features or products, even in innocuous ways.") That makes it difficult to document half-built features. As a rule: if a feature isn't usable yet, don't include it in a release. They cause bugs to be filed and extra effort to track. How dynamic is the documentation supposed to be? The intention is to describe the functionality as it exists now.
For functionality that is a proof of concept (for instance, Inventory Elastic Search), be sure to document it as such. The current plan is to have Inventory-ES replace the existing search technology in the Inventory app and get back to have one "Inventory" app. Thin-thread (does something to completion, even if most users won't use it...short-cut) example: the ability to make requests based on a hard-coded status value. It would be nice to have more customization/control over these things, but that is not how it is developed. This should be documented as it exists, including the limitations. Also, be aware of how the thin-thread conditions can affect future feature development. | |||||||||||||||||||||||||
| 30 min | Calendar functionality
Questions
| Areas like this also cause problems for releases; when underlying components are updated (Stripes, RMB, etc.) there is no team to do the upgrade. What is the priority of the calendar work? Would the RA SIG deprioritize other work to have this fixed? The calendar was not near the top in a recent prioritization of the RA SIG. Libraries that are live are seeing the impact; that may be why there is other circulation functionality that is ranked higher. Performance of other functions is tied back to the calendar implementation: check-out requires the calendar, and the way data is stored and the actual due date calculation is a big performance problem. Difficulty in the user interface of the Calendar app is a separate issue from the performance of the back-end. Support SIG reports that the Calendar app has one P1 issue, one P2 issue, one P3 issue. The SIG is raising this now as an early warning of potentially a critical problem in a future FOLIO release. The SIG should be cautioned that prioritizing the UI redevelopment does not address the other concerns for the app. Calendar is one of the pieces that is being investigated as part of check-in and check-out being slow in high-concurrency situations.
How does a SIG clearly specify what the problem is to get to the point of engaging a development team? It may not be the RA SIG; the initial analysis may need a working group including SMEs and developers. In general, there is an overlapping PC/Roadmap/Capacity-Planning set of concerns. Having a piece of the core system that no one seems to understand from a code perspective is something that needs addressing whatever the underlying issues. Vega is helping out with bug fixes. The Team vs module responsibility matrix has it assigned to them. Cheryl will work more on the specifications of the problem, bringing in others from the RA SIG and FOLIO implementors as well as possibly developers from the Vega team. This will likely then come back to product council. | |||||||||||||||||||||||||
...