Page Comparison

...

• 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

    If not, should we activate portions of Mwaya’s e2e suite for high priority areas - e.g. user creation flow

    • 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
    

Action items:

•  Review previous retro’s action items
•  SPIKE on the depth of navigation issues (See

  Jira Legacy
  server System JIRA serverId 815f41e5-e5fb-3402-8587-82eccc3ffab0 key LF-4022

  )
•  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! (See

  Jira Legacy
  server System JIRA serverId 815f41e5-e5fb-3402-8587-82eccc3ffab0 key LF-4021

  )
•  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