Background
This retro is for the S78: Friday, January 5th - Wednesday, January 17th
Please add comments before the meeting! We’ll take a few minutes to add additional comments and discuss, then put together action items to operationalize suggestions.
Last sprints (S74) retro is here: S74 Retrospective
Discussion topics:
After action review (AAR) for https://github.com/LiteFarmOrg/LiteFarm/releases/tag/v3.6.2
User perspective: When editing a revenue or expenses it appeared that the user was being kicked out of LiteFarm (in reality the browser was navigating several pages back).
Technical perspective: Broswer navigation takes place in several ways. Pertinent method is a custom function Jimmy built - to help persist data in multi-page forms; this works by pushing certain routes to a history stack. These are popped when you cancel or finish a form. We introduced a redirect such that when you popped these routes it took you too far.
Learnings:
Duncan found other forms (specifically in Finances) that navigation was broken too
Decided to do redirects instead of changing routes to keep consistent URLs; …
The hook that handles navigation conditions programmatically is a bad idea - evolved from 3 lines to a whole soup of edge case logic and no tests; there may be ways to simplify this or just allow the browser to handle navigation
Call this “route tech debt”?
We are doing some “very weird things with navigation” - logic was generic enough that it was very difficult to troubleshoot - might be easier to make it explicit, e.g. “If clicked from X, return to X after”.
Some requirements are asking for changes to the default browser behaviour - e.g. if a user clicks back after submitting a form, they shouldn’t be taken back into the flow.
Success: good patch and a good re-write of routes
On-going concerns: Lots of bugs around use of “<“ and back button; SPIKE to at least understand the shape and depth of navigation issues
After action review (AAR) for https://github.com/LiteFarmOrg/LiteFarm/pull/3073
Email field provided was not appropriately populating on the user detail creation screen - because this email field was read-only a user was not able to create a username / password based user account
Technical explanation: Joyce Sato-Reinhold; subtle and difficult to catch from the coding end
Learnings:
No route change here - just showing different components. Despite this, we’re using navigation. Instead we should just be handling this through React.
Look for conditional jsx rendering
There may not be a “safe” release - eschewing sanity was a mistake
Coded in a high risk way - esp. changing routes - not raised as a concern as this became more obvious
Think about cascading issues / top level changes will have many tendrils x 2
Bias: it needs to happen within this time frame or not at all
Should everyone be somewhat involved in release-scope items? Joyce reviewed PRs but wasn’t part of the earlier design processes
Fall 2023 was a fairly hectic period
We sped up the releases cadence to 1) get code to users quickly and 2) to become more comfortable with releases and 3) get more comfortable quickly responding to bugs - these objectives were successful albeit at the cost of some fairly large bugs.
Patch itself went really well - successful and enjoyable
State of automated testing, specifically around https://github.com/LiteFarmOrg/LiteFarm/pull/2931
Is this ready to be merged in?
Yes, but they won’t pass initially - we’ll need to do some refactors afterwards
Report back on scope of coverage
Devs will need to meet and get on the same page
E2E is not a silver bullet; need to think through a more holistic testing approach
Sanity week
Did I miss something about why there wasn't one?
Tacit groupthink that it was “not that big” - just a “cool patch”
We hadn’t started planning a full sanity and release for the month prior
Sanity is a big investment with a lot of planning; is this in line with our goal of speeding up release process? How does sanity evolve in light of this goal? Team bug hunt day?
Tech debt
As we build more new features we create more tech debt – it feels that more tech debt could be prioritised
Engineering team responsible for bringing tech debt themes to grooming and prioritizing into each sprint
Start doing | Stop doing | Keep doing | Shout outs |
---|---|---|---|
|
|
|
|
Action items:
- Review previous retro’s action items
- SPIKE on the depth of navigation issues.
- Update from React router version 4 to 5 or 6? Anto says there are guides on how major versions will change. Will probably be a mix of issues known a priori and those found afterwards. Need to bump our React version too? No!
- Look into Jira: is there a way to calculate and track the portion of time spent on feature vs tech debt Anto Sgarlatta
- Make sure each sprint has a few tech debt tickets, even when the focus of the sprint is feature development Anto Sgarlatta
- Anto Sgarlatta to discuss current implementation of app styling with Loic Sans during next 1-on-1
- Begin a Confluence doc on things you want to learn and things you’re interested in teaching and then schedule sessions around them Anto Sgarlatta
- Lite Farm to schedule a team discussion on the appropriate mechanisms for verifying a release will be successful (e.g. bug free)
- Denis Dovganyuk to begin labeling bugs with “Inconsistently reproducibility”
- Investigate automating the addition of a release tag based on the current version number (e.g. “3.7.x”) to a ticket when moving it into “Resolved” or “Release Ready” Anto Sgarlatta