Team Roles

Team Roles

QQQ is developed by a small team of 4 people who all have full repository access and contribute across all areas.

Quick Links

• Home
• Contribution Guidelines
• Decision Logs
• Feature Development

Team Structure

Simple Rule: We're all equals with full access. No hierarchy, no formal roles.

graph TB
    subgraph "QQQ Team (4 people)"
        A[Person 1<br/>Backend Focus]
        B[Person 2<br/>Frontend Focus] 
        C[Person 3<br/>DevOps Focus]
        D[Person 4<br/>Architecture Focus]
    end
    
    subgraph "What We Do"
        E[Code Review<br/>All PRs need approval]
        F[Release Management<br/>Consensus on versions]
        G[Architecture Decisions<br/>Discuss and agree]
        H[Quality Standards<br/>Enforce our rules]
    end
    
    A --> E
    B --> E
    C --> E
    D --> E
    
    A --> F
    B --> F
    C --> F
    D --> F
    
    A --> G
    B --> G
    C --> G
    D --> G
    
    A --> H
    B --> H
    C --> H
    D --> H

Loading

How We Work

Code Review

• Every PR needs approval from at least one other team member
• We all review each other's code - no assigned reviewers
• Quality gates must pass (Checkstyle, tests, coverage)
• Merge when approved - no waiting for multiple approvals

Release Decisions

• Discuss timing in team chat or issues
• Cut release branches when we agree it's ready
• Hotfix decisions - whoever spots the issue can propose
• Version bumps - discuss breaking changes as a team

Architecture Changes

• Big changes: Discuss in issues first
• Small changes: Just do it, we'll review in PRs
• Breaking changes: Must have team agreement
• New modules: Propose and discuss before implementing

Quality Standards

• We all enforce the same standards
• No exceptions for anyone on the team
• Automated checks must pass (CI/CD)
• Manual review catches what automation misses

Decision Making

Simple Process

1. Propose - Create issue or discuss in chat
2. Discuss - Team gives feedback
3. Decide - Whoever cares most makes the call
4. Implement - Do the work and submit PR
5. Review - Team reviews and approves

When to Discuss

• Breaking changes that affect users
• New major features that change the framework
• Performance changes that might impact users
• Dependency updates that might break things

When to Just Do It

• Bug fixes and small improvements
• Documentation updates
• Test improvements
• Code refactoring (non-breaking)

Communication

Channels

• GitHub Issues: Feature discussions and bug reports
• GitHub PRs: Code review and technical discussions
• Team Chat: Quick questions and coordination
• Wiki: Documentation and decisions

Meetings

• As needed - no regular schedule
• Quick syncs when coordinating releases
• Architecture discussions when planning big changes

Escalation

Disagreements

• Talk it out directly with each other
• Present data - show why your approach is better
• Compromise - find middle ground when possible
• Team vote - if still stuck (rare)

Priority Conflicts

• Discuss impact - who does this affect most?
• Consider effort - what's realistic to deliver?
• Align on timeline - when does this need to be done?
• Split work - can we work on multiple things?

What We Don't Do

• Formal role assignments - we're all maintainers
• Complex approval processes - one approval is enough
• Scheduled meetings - we meet when we need to
• Hierarchical decision making - we discuss and agree
• Formal performance reviews - we give feedback directly

Getting Things Done

Quick Start

1. Pick an issue you want to work on
2. Create a branch and start coding
3. Submit PR when ready
4. Get approval from another team member
5. Merge and move on

Bigger Changes

1. Create issue describing what you want to do
2. Discuss approach with team
3. Get agreement on scope and approach
4. Implement incrementally with small PRs
5. Review and iterate based on feedback

See Also

• Contribution Guidelines - How to contribute
• Code Review Standards - Review process