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