Page Comparison

Cate Boerema (Deactivated)

• Several Core team Q4 features are at risk, but I am reluctant to move them out of the quarter, as we are hoping we can make at least some progress before feature freeze. POs for other teams are probably doing the same. Here's the full list of at-risk features across teams. There are 22 (of the total 107 targeted).
• I have tagged the features and stories coming out of the November Chalmers visit. View the list here.
• Circulation is still a risk area for Chalmers go-live. Specifically:
  • Request policy still be designed (re-designed) and some elements may be moving to the Loan policy. Cate, Sean and Tania working to get this nailed down for the developers asap
  • While some aspects of circulation are independent enough to be worked by a team other teams (e.g. loan and request policy CRUD, extending the loan rules editor) making these new policies effective will really need to be done by the Core team.
  • Making policies effective needs to be done in exactly the same code being modified for other ongoing circulation features such as in transit to home location and fulfilling pickup requests. Not a lot of work can be done concurrently here.
  • Title requests - still not clear what the plan is here.
  • Library opening hours calendar - Sean is finding bugs and issues with this Qulto-developed app. Which team is responsible for maintaining it? Sean would be the best fit from a PO perspective given his other features are primary consumers of calendar data.
  • Here is a list of circ related features likely needed by Chalmers to go live which will need to carry over in some form to Q1. The list is long and there are dependencies.
• Leipzig is hosting a self-built article index and are providing the data to a number of German libraries, most of them using vuFind discovery systems (are mostly hosted by Leipzig). The infrastructure/community is named finc. They are now getting ready to re-implement their configuration software on FOLIO. The code will of course be open source and re-usable, if there are any institutions interested in this kind of set-up. I have implemented a JIRA project (UIFC) for them to track their requirements.

Cate Boerema (Deactivated)

• Chalmers visit was very productive - Have a clearer understanding of their must-have workflows. Uncovered some gaps which will be logged as features in JIRA and discussed with the relevant SIGs
• Need to decide on sprint review schedule during the holiday, as the normal cadence would have the next demo on Christmas day. Some options:
  • Tuesday Dec, 18
  • Thursday January 3
  • Tuesday January 8 (one week before release - too late?)
  • NOTE: Release is Monday January 14
• Risks:
  • Circulation is a very high risk area for Chalmers' ability to go live
    • In transit to home location (not to fulfill request) - This feature required lots of new plumbing and is at risk of not being completed in Q4. It is a pre-requisite for Fulfill pickup requests (see next bullet)
    • Fulfill pickup requests - This can't begin until In transit to home location (previous bullet) is complete. It is a very large feature and likely to not even be started in Q4.
    • Extending Loan Rules Editor to target additional policy types - Critical to the completion of Requests (request policies) and Patron notices (notice policies). Will likely need to be pushed to Q1.
    • Setup/configure patron notice logic (Patron Notices Policies) - Critical to the completion of patron notices. Likely to be pushed out of Q1.
    • Scheduler - Prerequisite for completion of patron notices and not started (wasn't actually targeted for Q4, but should have been)
• Cap plan model has been updated
  • Need to review feasibility of Q1 targets with POs and get back to Product Council and Chalmers with our findings

Jakub Skoczen

• Mid sprint 51

• Backend issues critical for completing functional work:

  • CIRC-154: check-in by barcode API (IN PROGRESS by William, to be handed off to Marc). William will issue a PR today and Marc will handle the review and any remaining work, once completed it will allow to unblock CIRC-146

  • CIRC-146: Change status to "in transit" upon check-in (IN PROGRESS handed over from Jeremy to Marc). Emma, Marc and I had a good meeting about specific uses cases and requirements not flashed out earlier (e.g repeated check-in/scan). We have also discussed extensions to handle pickup requests (a backend prerequisite for  UXPROD-118), they seem quite manageable and contained but we decided that they will not be in scope for CIRC-146 to avoid putting UPROD-601 under threat.

  • CIRC-150: validation of check-in/check-out SP during loan CRUD (IN PROGRESS re-assigned to Kurt from Jeremy) required to complete UIU-485

  • CIRC-151: Make mod-circulation Service Point enabled (DONE, Kurt)

  • CIRC-156: dereference patron group ID to display the name along with the request (IN CODE REVIEW, Kurt) no longer blocks UIREQ-114, needs handling of permissions

  • UIREQ-144: Aditya has completed development work and put the issue IN REVIEW
    
    

• Cross team

  • Kick-off meeting about the PubSub support in FOLIO based on the earlier proposal from Adam and Jakub happened last Wednesday, it has been decided that the proposal meets EPAMs requirement and the EPAM team will move ahead with implementation of mod-pubsub and "scope" functionality in Okapi.
    https://docs.google.com/document/d/1L0qJ6VEmlKU4UCfznnc7du9qPZpjVq3DhcW68leIgEY/edit
    
    

• OKAPI/RMB, performance NFRs

• MODINVSTOR-215: During the meeting with EPAM Postgres experts on Tuesday it has been decided that Julian will continue with a solution similar to what has been proposed and he will implement the solution in RMB. The Core Team will not need more support from EPAM. (see RMB-301)

• Adam is working on reference data loading; RMB-296 and MODINVSTOR-216
  
  

• Devops:

  • FOLIO-1577: Created automated builds for 'next-release' (IN PROGRESS, John) – there were missing releases blocking completion of this issue and it has become the focus of the last devops call. We have decided that it is not devops responsibility to request specific backend or front-end module releases, on the contrary – new "next-release" builds should be triggered by availability of new module releases. The specific dependency issues that prevent the current build are being investigated by Marc and John. We have decided to put additional guards in place to ensure that future releases are free from those dependency issues (OKAPI

  • FOLIO-1548: Create a lighter-weight folio/testing-backend VM – the SPIKE has concluded and the approach is to slim down the Vagrant VM and provide ability to load additional modules dynamicall (STCLI-15, STCLI-114)