Future Audiences/Team Norms

This page is intended to document norms adopted by the team. It is recommended to review these norms at least quarterly.

This is a living document, and should evolve over time!

Last updated: 10 Dec 2024.

Rituals

We aim to set up the following standing meetings:

Caption

Ritual	Attendees	Frequency	Purpose	Agenda
Standup	All team members	5x/week	Sync daily progress and identify blockers.	(Slack only) Post : what are you working on today? Any blockers or questions?
Replenishment	Product Owner, Team Leads, Optional: Stakeholders	30 minutes / weekly	Prioritize and pull new work into the flow.	1. Review the backlog 2. Prioritize items based on current information 3. Pull prioritized items into the workflow as per WIP limits.
Refinement	All team members, Product Owner	1 hour / every 2 weeks	Clarify and estimate upcoming work.	1. Go through upcoming tasks 2. Discuss details and requirements 3. Break down tasks if necessary 4.. Estimate effort and resources.
Engineering Sync	Development Team	30 minutes / weekly	Technical alignment and sharing of information.	1. Discuss ongoing technical challenges 2. Share new tools, practices, or learnings 3. Identify blockers
Retrospective	All team members	1 hour / every 2 weeks	Reflect on the past cycle and identify improvements.	1. Discuss what went well and what didn’t 2. Identify actionable improvements 3.. Agree on changes to implement in the next cycle.
Release Preparation	All team members	1 hour / as needed (pre-release)	Ensure readiness for release and coordinate deployment.	1. Review items marked for release 2. Finalize release notes 3. Discuss deployment steps and timelines 4. Assign responsibilities for release tasks.

Communication

• We primarily use Slack for team communication
• Engineers may occasionally need to use IRC to communicate with certain community members or other teams (eg train releases)
• To ensure context sharing, default to fully public channels for discussion wherever possible, unless discussing sensitive or private information

Issue Tracking

• We will use Phabricator for tracking all project issues.
• All priorities should be tied directly to a phabricator ticket
• We use kanban-style issue tracking via this board, which involves:
  • Limiting the amount of work currently in progress
  • Periodic issue refinement to ensure readiness
  • Ordered priorities within columns : top = highest priority, bottom = lowest
  • Moving tickets through four columns
    • Backlog = to be refined work
    • In Progress = Work currently in progress by any team member
    • In Review = work in code review
    • Done = Ready to be signed-off on work

Definition of Ready

A task is ready to take on when it has the following properties:

• The description has been filled out according to the task template (TBD)
• The task has been estimated by project engineers and an estimate has been asigned
• The task has been reviewed by product managers and it has been placed at the appropriate location in the column according to priority

Code Best Practices

• We use gitlab for source code management and code review
• All source changes require review in the form of a gitlab pull request
• We use trunk-based