Ways of Working

NOTE

This represents the target state for Phase 3 of the WoW proposal.

Teams

Role	Appybaras	Appricots
Senior BE	Phil
Mid BE	Gadiza
Senior RN	Eugene
Mid / Senior RN	Peter
QA	Dave
QA	Joel
Designer	Simon
PM	Emily	Emily
Captain / Lead	Samantha	Samantha

Contacts

Situation	Contact
Bug in production	Bug ranger (see rota below)
Feature requests	PM
Access/permissions	App Lead
Build/CI issues	App Lead
Design questions	Team designer
External contributions to app code	App Lead

Communication Channels

Channel	Purpose
#appybaras	Appybaras daily discussion
#appricots	Appricots daily discussion (TBC)
#app-engineering	Cross-team tech discussion, RFCs, announcements (TBC)
#incidents	Production issues
#customer-app	Releases and updates to customer app
#engineer-app	Releases and updates to engineer app
#appyblokes	App devs chat (currently private)

Meetings

Meeting	Cadence	Purpose
Stand up	Tuesdays	Sync stand up; async on other days
Planning	Once per sprint	Sprint planning
Sprint check-in	Once per sprint	Mid-sprint progress check
Retro	Monthly	What's working, what's not
Architecture sync	As needed	Cross-team tech decisions — new patterns, shared code RFCs, tech debt prioritisation

Bug Ranger Rota

Not yet active

Bug ranger rota has not been set up yet.

Weekly rotation — 1 BE dev and 1 app dev per week, alternating between teams. Handoff happens Monday morning, aligned with release day.

Responsibilities:

Task	Frequency
First responder for incidents	As they arise
Check Sentry	Daily
Triage/fix small issues	As they arise
Security package updates (npm audit)	Weekly check
Dependency bumps	As needed
Handoff notes	End of week

Escalation path:

1. Ranger triages
2. If in ranger's team domain — fix it
3. If in other team domain — assign ticket, ping team in Slack
4. If critical — pull in App Lead or both seniors

Project Management

• Appybaras Jira Board: https://zuno-tech.atlassian.net/jira/software/c/projects/APY/boards/46
• Appricots Jira Board: TBD

Definition of Done

• [ ] Code reviewed and approved by another dev
• [ ] Tests reviewed by QA
• [ ] QA manual testing passes
• [ ] E2E tests pass (into develop only — not required for tickets into a feature branch)
• [ ] Documentation updated (if applicable)
• [ ] Accepted by relevant stakeholders
• [ ] Merged into develop

Jira Workflow

Ready for Development
        ↓
   In Progress        ← Dev working
        ↓
 Ready for Review     ← Dev done, PR open
        ↓
  Ready for QA        ← Code review passed
        ↓
     In QA            ← QA testing (see note below)
        ↓
   Acceptance         ← QA passed, stakeholder review
        ↓
 Ready to Merge       ← Accepted, waiting for merge
        ↓
  Ready for Live      ← Merged, in next release

What "In QA" means depends on the target branch

• Into a feature branch: manual testing only. E2e tests are written at the end of the epic.
• Into develop: manual testing + e2e tests must pass before merge.

Who moves tickets

From	To	Who
Ready for Dev	In Progress	Dev
In Progress	Ready for Review	Dev / jira automation on PR open
Ready for Review	Ready for QA	Dev (PR approved)
Ready for QA	In QA	QA
In QA	Acceptance	QA (testing passed)
Acceptance	Ready to Merge	Stakeholder(s)
Ready to Merge	Ready for Live	Dev (after merge)

Branch Strategy

Naming Convention

Use the dev branch suggestion from Jira, or name it manually starting with the ticket number. The branch must start with the ticket ID so PR builds get posted to the correct ticket.

Format: ABC-123-short-description

Rules:

• Must start with Jira ticket ID (for auto-linking and PR build comments)
• PRs targeting a feature branch must have the FEATURE_BRANCH label

Cross-Team Code Reviews

PRs touching src/design-system/ require a reviewer from the other team.

Release Schedule

NOTE

This covers app releases only — the mono has its own release process. We should aim to align BE and FE changes where possible to avoid mismatches.

Fortnightly releases:

• Thursday — put in review on app stores (Friday allowed if there's run-over)
• Monday — release to users

Release captain alternates between teams each release so everyone knows the process. Both teams agree on phased vs immediate rollout and release notes before each release.

Store Release

Step	Owner	Automation
Announce intention to release + warn about freezing merge queue	Release captain	Manual
Freeze merge queue	App Lead / QA	Manual
Run e2e suite / review last night e2e	QA	Manual
Bump version and tag commit	Release captain	Manual
Wait for prod + prod-e2e builds	Release captain	Automated
Run prod-e2e tests and verify	QA	Manual
Release notes	PM	Manual
Submit to stores	Release captain	Manual
Merge develop into main	Release captain	Manual
Resume merge queue	App Lead / QA	Manual

NOTE

When actually released, inform the relevant app channel

OTA Release

Step	Owner	Automation
Alert app lead asap	App lead	Manual
Announce intention to release	Dev doing the fix	Manual
Fix merged to main	Dev	Manual
Run e2e tests on main	QA	Manual
Tag commit with OTA version (which automatically releases)	Dev doing the fix	Automated
Notify app teams + relevant app channel	Dev doing the fix	Manual