Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties

Background

This retro is for the August 2023 release. Sanity began on Monday, July 31st and we released on Friday, July August 4th.

Retrospective

Info

Discussion topics:

  • Changes to /wiki/spaces/LITEFARM/pages/1339064341?

  • Changes to kanban structure or workflow? https://lite-farm.atlassian.net/jira/software/c/projects/LF/boards/10

    • Don’t batch move tickets from status to status (because it causes priority ordering to be lost)

    • Adopt priority indicator on tickets

    • Don’t show icebox column?

    • Who puts a ticket into language review? QA makes the decision to put in “Release ready” or “Needs language review” based on presence of language tags

  • Code freeze?

    • Freeze before sanity week

    • Separating bug squash from sanity?

  • Testing strategy

    • Split release into two segments: bug squash then sanity

    • What do developers do during sanity week?

      • Could be testing

      • Could be other activities

  • Tester strategy

    • Ask for more dedication and put payment towards time involved?

      • Cost benefit analysis of manual testing assistance against automated bug detection on CI

    • Less “come and go as you please”

    • In advance of sanity, ask people there availability and try to “chunk” them into different categories (e.g. crop plans, locations, finances)

    • There is a disadvantage to giving people a script or pre-loading data. You don’t see bugs that exist because of poorly understood dependencies

  • Friday release (why not wednesday/monday?)

    • Relic of sanity week and time to resolve bugs

    • Can be revisited with discussion of restructuring release process

  • Release more often - maybe instead discuss release more often

    • Potentially reviewing at the start of each sprint, “Are we ready to release”?

      • A yes would initiate the release script / communications with the community

    • Still maintain a static release date, but be more flexible based on features / where the code is at each sprint

      • How would we involve the community in ad hoc releases?

    • A key factor for the static release date far in advance is to allow for advising testers for sanity

      • Having dedicated testers could potentially remove this complexity

  • S66

    • estimated story points

    • google meets

    • tech debt in every sprint

    Friday release (why not wednesday/monday?)

Start doing

Stop doing

Keep doing

Shout outs

  • Setting expectations inside the core team on processes in advance

  • Code freeze before sanity week

  • Fewer testers but more in-depth?

  • Pause and reflect a moment longer before rebooting prod 🤔

    • Mandated 30 second pause + invitation of dissent on certain actions?

  • Complete translations before sanity week (part of the definition of code freeze)

  • Troubleshoot SurveyStack starting from the more basic elements before jumping into the most complex (codebase, export server, etc.)

  • Add more concurrency testing to sanity script

  • Release one week after core feature

  • Don’t merge integration to main until integration is 100% ready (e.g. code version, blog link, translation tags)

  • Early as possible code freeze

  • Chilled music during retro

Action items:

  •  Review previous retro’s action items
  •  Lite Farm to set-up a discussions for proposing / discussing / reviewing sanity strategy
  •  Lite Farm to set-up a discussion for how to best involve testers in sanity
  •  Add more concurrency testing to sanity script Denis Dovganyuk
  •  Lite Farm to create page for S68 and reference for this page and S66
  •  Create “Mandated 30 second pause + invitation of dissent on certain actions?” list - Joyce Sato-Reinhold
  •  Write-up a Confluence page on “Code freeze” for contributors
  •  Denis Dovganyuk and Joyce Sato-Reinhold to meet and go through testing processes for SurveyStack integration