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: 15 Apr 2024.

Rituals

We aim to setup the following standing meetings:

Caption

Meeting	Frequency	Description & purposeW	Invitees	Owner
Standup	3x/week: MWF	Virtual, bot-lead in #future-audiences-private channel: What are you working on today, what blockers or questions do you have?	Full Team
Priorities Sync / Kanban Replenishment	1x/week: M	Discussion of current priorities for the week, led by PM	Eng + Design + PM
Task Refinement	1x/week: Th	Refine tickets to ensure they meet definition of ready	Eng + Design + PM
Retrospective	1x/2 week: M	Discuss what is going well, could be going better, and what actions to take in response	Full Team
Engineering Sync	1x/week: M	A place for engineers to sync on technical approaches and blockers at a higher level	Engineers

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