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: 07 Nov 2025.
Rituals
[edit]We aim to set up the following standing meetings:
| Ritual | Attendees | Frequency | Purpose | Agenda |
|---|---|---|---|---|
| Standup | All team members | 3x/week | Sync daily progress and identify blockers. | What are you working on today? Any blockers or questions? |
| Demo | All team members, Optional: Stakeholders | 30 minutes / every 2 weeks (after sprint end) | Demo work completed in the last sprint. Discuss upcoming work/review roadmap. | 1. Demo new work
2. Feedback/questions 3. Review upcoming roadmap items |
| 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. |
| Retrospective | All team members | 1 hour / every 2 weeks | Reflect on the past cycle and identify improvements. | 1. Review previous action items
2. Discuss what went well and what didn’t 3. Identify actionable improvements 4. 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
- Ensure that Communications Team is linked in to our work- Liv will drop in to our stand ups once a week.
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
Process Best Practices
[edit]- We like to set artificial deadlines so that it drives urgency and limits analysis paralysis
- We chase results and learning, not perfection
- We execute on projects with a specific audience in mind
- When appropriate, we commit to publishing two versions of something so that we can measure what worked and what didn't
- We like getting all parties into a room to brainstorm and create an idea together