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
[edit]We aim to setup the following standing meetings:
| 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
[edit]- 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
[edit]- 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
[edit]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
[edit]- 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