2021-08-05 Product Council Meeting Notes

Owned by Kristin Martin
Last updated: Aug 06, 2021 by Gang Zhou
4 min read

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
5 minAnnouncementsKristin Martin

August meeting reminders

  • August 12 meeting is canceled
    • SIG Conveners will be able to provide a written update here (using this template). Note any topics requiring discussion for the August 19 meeting
    • Review of PC charter to occur around August 26 meeting following vacations
  • New FOLIO members (as announced in the Community Council):
    • Hangzhou Metadata Technology Company Limited: Fang Xuguang - slides
    • JIANGSU JIATU NETWORK TECHNOLOGY CO., LTD: Lei Zhou - Web site
    • LMU Munich: Julie Bickle - slides
  • Go live announcements?
  • TC change: Mark Deutsch (Duke) departing project, Chulin Meng (Lehigh) has agreed to serve.
1 minBug Fest 

Kirstin Kemner-Heek

Bug fest is still not finished: test cases

  • Anton is asking for more smoke testers
  • August 10 - 12
  • Please approach Anton in case you are available or you need a test rail account
  • New smoke test environment will be announced in bug fest channel shortly
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 ( UXPROD-36 - Getting issue details... STATUS ). 

  • The setting to turn the UI display on or off is implemented - you can check a box in Settings>Users>Profile Pictures to indicate whether the gray box for the profile picture should appear. 
  • There is no functionality to actually upload and store profile pictures, so checking the box just means a gray box displays on the user profile in the app, with nothing else possible to do with it.
  • The feature hasn't been prioritized highly, but is proving to be confusing to new implementers of FOLIO

Questions:

  • What should FOLIO do if there are things in the UI that do not function and cause confusion, and there’s no expectation of it being fixed in the next release? If the thing is not removed, what should happen?
  • How could we handle explaining these types of situations in the documentation?
  • How does FOLIO balance the need to be consistent in the UI with development that may stretch over multiple releases?

(OLD ACCOUNT) Erin Nettifee

Kristin Martin

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.

  • Do not include in the UI functionality that isn't working (or is only partially working)
  • If there is something in a release that is non-functional or partially functionally, include that fact in the documentation.

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

  • This Google Document describes issues and concerns that have come up related to the calendar functionality

Questions

  • Are libraries experiencing significant issues with the calendar functionality?
  • Has the issue not been prioritized because of misunderstanding of the issues?
  • What would be implications of raising the priority of the calendar functionality?
  • What are potential actions the PC could take?

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.  UICHKIN-269 - Getting issue details... STATUS , UICHKOUT-726 - Getting issue details... STATUS  

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 FOLIO Module/JIRA project-Team-PO-Dev Lead 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.





Action items

  •