Present: Ben, Mary Jo, Josh, Chongsun, Rachel, Sam, Brandon, Nick

Meeting Goal

How do we ship software better or ship better software?

(EG, fewer critical bugs shipped in release versions, fewer last minute issues, fewer regressions, known performance levels, etc.)

Agenda

1. What went wrong in 3.2.0 release?
2. How to improve for future releases?

1. What went wrong in 3.2.0 release?

Requisition UI - Total Losses and Adjustments modal doesn’t update the order able lineItem (error messages)

Notifications - pending investigation from Nikodem

View Requisitions date filter - should be good in core

• Seems to resolved by clearing the cache
• @nick to look into the date filter for RCA

Requisition headers - not responsive

• Regression - input fields shrinking to the size
• To-Do: Need to put in unit tests on this code base
• Another idea: beef up the demo data to have more variety of layouts.

Requisition Error 

• Untranslated error messages
• Modal doesn’t go away
• To-Do: add unit tests, DRYer 

Token expiration 
Permission string generation migration
Performance validations need improvement for release improvements

Batch Requisition

• Performance issues
• 0s on approved quantities (not sure if this is a bug or misunderstanding)
• Null values break batch (null means the system thinks there was an intention to put zero

Need to Address/Tech debt
Requisition validations - not accommodating 31 days for Stock out Days
Performance

• Slow UI performance with multiple programs @nick and @josh to create a ticket about this issue

Offline notifications not consistent

2. How to improve for future releases?

Brainstorming from team:

• Better automated testing needed for continuous delivery principles
  • Idea: force quantity/coverage of unit tests
    • Require each bug fixed to have automated tests
  • How do we make cultural shifts to the team (for example, RCA -> unit tests)?
  • Can we use or check Sonar or enforcement of it?
• Too short of an evaluation period (overall and of new design/features)
  • 'Release Candidate' process
  • Feature flags
• Need a way to do evaluation (with the appropriate amount of time) of release candidate
• Slow down the release process
• Need more test data (both demo data and performance)
• Is there a way to have better tracking of code changes to components??
• Need to investigate or understand how caches are updated or if that is needed with new releases/updates. Need to understand the cacheing of the application (not data) strategy. Have to have a way to notify users of how to update the angular application.
• In addition, we need to address the data updates. (If we removed a set a fields within the requisition) - we aren’t snapshotting the templates 

Next Steps

• Mary Jo Kochendorfer (Deactivated) to make sure all the issues on the top of this page have updated tickets in OLMIS JIRA and get prioritized (please mark criticals, add to Sprint 35 grooming, etc)
• Team to identify the best ideas and turn them into action (Mary Jo Kochendorfer (Deactivated) perhaps dot voting and identifying prioritized next steps should be the topic of our retrospective this coming Wednesday instead of our usual open-topic retrospective)