Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Background

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

Retrospective

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

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
  • No labels