Team Processes from Team Discussions

This document captures team processes, workflows, and practices that emerged from team discussions. These should be integrated with existing team process documentation.

Release Process

Branch Strategy

Current structure (as of late 2025):

main → release (always locked) - deployed at momentum-staging
dev → main (never locked, default branch) - deployed at momentum-development

Branch naming:

Include ticket number in branch name
Branch from main for new features
Use release branch for release candidates

Release Workflow

Release branch management:

Release branch should be locked always
Need to merge everything from main to release at specified times
Process for changes to release branch needs to be established
Hotfixes branch from release when needed

Release process:

Container updates are merged post-release as part of deploy process
Release greenlight deadlines are set (e.g., Thursday 12pm ET)
Tickets are tagged for specific releases
PRs to main deploy to dev; PRs to release deploy to staging/release environment

Release Testing

Process:

Retest remaining tickets in the release
QA verifies tickets before release
Monitor logs closely after each deployment for errors
Release application needs to work with release branch

Release coordination:

Release channel (#release-XXX) is for logistics and coordination between QA and dev
Not for code review requests (those go in #tech_pull-requests)

On-Call and Incident Response

On-Call Rotation

Current needs (as of late 2025):

Expanding rotation roster due to NYCA requirements and end-of-year coverage
Need reliable paging for NYCA 6h max app downtime requirement
Need backup/escalation mechanisms to reduce stress on single on-call person

Tooling considerations:

Evaluating on-call and escalation tools
Need for consent process proposal for tool selection
Multiple platform options to evaluate

Incident Response

NYCA requirements:

6-hour maximum app downtime requirement
Need reliable alerting and escalation
May require expanded on-call coverage

Sprint and Work Management

Sprint Planning

Daily standups:

Daily ping in #_daily-ping channel
Each person pings at start of their workday in their timezone
Status updates and notes on tickets

Mid-sprint check:

Halfway through coding time for sprint
Review planned tickets
Identify tickets that need to roll over (won’t be done by code freeze Tuesday)
Comment tickets with status updates and/or notes

Ticket Management

Best practices:

Assign tickets when starting work on them (makes tracking clearer)
Link issues to PRs (visible via “bullseye” icon in GitHub)
Update ticket status as work progresses
Tag tickets appropriately (e.g., scope-builder-qa for related work)

Ticket standards:

Feature tickets should follow standards (work in progress to create issue templates)
Too many issue templates currently - need consolidation

Work Coordination

Before starting feature work:

For “feature” size tickets: Call ad hoc meeting or make Slack post before starting
Small tickets and bugs: Fine to just start

Communication:

Post in Slack when starting significant work
Coordinate with team on overlapping work
Use dedicated channels for specific topics (e.g., #tech_pull-requests for PR reviews)

QA Processes

QA Constitution

Work standards (draft as of late 2025):

Outlines work standards for QA team
Some practices reflect current good feedback
Some represent aspirational goals for QA practice
Being refined heading into 2026

QA verification:

QA Verified status indicates someone other than author verified specifications met
Additional issues/edge cases documented for tracking or backlog
Corresponding PR approved but not merged until QA verified

Testing Workflows

QA testing:

Test on staging environment
Verify features work as specified
Document edge cases and issues
Coordinate with dev on fixes

Development Workflow

Feature Development

Process:

Create/assign ticket
Branch from main with ticket number in name
Develop feature
Create PR linking to issue
Code review
Merge to main (deploys to dev)
QA testing on staging
Merge to release when ready (deploys to staging/release)

For large features:

May need design docs
May need feature flags
Coordinate with team before starting

Code Freeze and Releases

Code freeze:

Typically Tuesday before release
No new PRs merged to release branch
Focus on testing and bug fixes
Tickets that won’t be done roll over to next release

Release preparation:

All release tickets should be merged and tested
Release branch locked
Final testing and verification
Deploy to production

Communication Practices

Channels

Dedicated channels:

#tech_pull-requests: For PR review requests (not release-specific)
#release-XXX: For release logistics and QA/dev coordination
#_daily-ping: For daily standup pings
#tech_momentum: For product/development discussions

Channel purposes:

Keep channels focused on their intended purpose
Don’t clutter release channel with PR reviews
Use appropriate channels for different types of communication

Documentation

PR documentation:

Include clear descriptions
Add screenshots, videos, or demos for complex changes
Document shortcuts or workarounds
Update documentation when making setup/process changes

Wiki/documentation updates:

Update when making significant changes
Communicate changes to team
Keep documentation current

Retrospectives and Process Improvements

Retro Decisions

Example decisions from retros:

New branch strategy implementation
Add ticket number to every commit
Devs call ad hoc meeting or Slack post before starting “feature” size tickets
Experimentation with removing legacy code (e.g., CPC code)
Pairing to understand technical dependencies (e.g., freeing Momentum from BKB)

Learning practices:

To get more confidence from AI tools: Have different instance check previous instance’s work
Share learnings in retros
Document decisions and rationale

Scope Builder Refactoring

Refactoring Approach

Goals:

Combine multiple Livewire components into one
Eliminate inter-component communication issues
Consolidate business logic
Improve DOM morphing performance
Make testing more straightforward

Considerations:

Will create large single file (2,300+ lines)
Need to resolve name conflicts
Benefits: Single source of truth, better caching, easier maintenance

Coordination:

Multiple people can work on subtickets in parallel
Main ticket requires coordination to avoid conflicts
Regular communication about progress and approach

This document is a synthesis of team discussions. For official processes, see the main Team Processes documentation.