Updated checklist:


- Check HATS, ensure errors are at zero.
- Deploy code changes to a testing environment (e.g. EDF DEV07).
- Request developer to internally verify.
- Determine if ticket should be part of future 24.1 release
- Once ticket is verified internal, If ticket should be part of future 24.1 release add "Ready_for_Release" label, add fixVersion 241_UPDATES.
- Determine if this ticket is categorized correctly (bug, story, improvement or task)
- If ticket is categorized as story, make sure the title/summary is phrased correctly ("As  a (user  role), I want  to (activity), so that  (business  value)")


DAS Harmony Verification

Suggested checklist for Harmony related tickets (Owen's suggestion):

I tried to start a draft Smart Checklist for Harmony tickets - this probably isn't a complete list, but it's maybe something we can iterate. (So we aren't skipping half the list that relates to on-premises work):

  • Deploy changes to SIT Harmony environment.
  • Request developer to internally verify.
  • If ticket produces a new service version, add "Harmony_Release" label.
  • If ticket should be part of on premises release add "Ready_for_Release" label, add fixVersion 241_UPDATES (Maskfill/Trajectory Subsetter)
  • Determine if ticket is categorised correctly (bug, story, improvement, task)
  • If ticket is categorised as "story", make sure the title is phrased correctly ("As a (user role), I would like to (activity), so that (business value)")
  • Once ticket is verified, notify appropriate Slack channels of pending UAT release.
  • Request Harmony team updates version used in UAT.

Other open question: do we still need to use the "not_part_of_release" label? It's a tiny bit demoralising (and misleading) to need to use it for Harmony-related work. (Although, the "Harmony_release" label has helped mitigate this a bit)


  • No labels