ZeroVerify Team Charter

Standard Operating Procedures for ZeroVerify team

Version 1.1 | Last Updated: February 2025

Team Members

Communication Protocol

Channels

Response Time Commitments

Communication Standards

Meeting Schedule

All meeting times are arranged and agreed upon in the Discord group channel to accommodate team members” schedules.

Sprint Structure (2-week iterations)

Sprint Planning

Daily Standups

Backlog Refinement

Definition of Done

A task is DONE when all criteria are met:

  1. Code pushed to feature branch with descriptive commit messages following conventional commits format

  2. Pull request opened with:

    • Clear description of changes

    • Link to related issue/user story

    • Screenshots/test results if applicable

  3. At least one other team member has reviewed and approved the PR

  4. All tests pass (unit tests minimum, integration tests where applicable)

  5. Documentation updated:

    • README if setup changed

    • API documentation if endpoints modified

  6. Code merged to main branch

Code Quality Standards

Blocker Management

Recognizing Blockers

You are blocked if:

Resolution Process

Phase 1: Self-Help (0-4 hours)

  1. Document the problem clearly (what you’re trying to do, what’s failing)

  2. Search existing resources (project docs, GitHub issues, relevant documentation)

  3. Attempt at least two different approaches

  4. Timebox your struggle at 4 hours maximum

Phase 2: Team Assistance (4-24 hours)

  1. Post in Discord channel with:

    • Clear description of the blocker

    • What you’ve already tried (show your work)

    • Specific questions or help needed

    • Tag relevant team members

    • Urgency level: [CAN CONTINUE OTHER WORK] or [COMPLETELY BLOCKED]

  2. For complex technical blockers:

    • Request 15-30 minute pair programming session

    • Scrum Master facilitates scheduling within 24 hours

  3. Decision timeout:

    • If no technical consensus within 24 hours, trigger Technical Tie-Breaker

Phase 3: Technical Tie-Breaker (for deadlocked decisions)

When team cannot agree on technical approach after 24 hours:

  1. Each side prepares written proposal (max 1 page) covering:

    • Alignment with project goals (security, privacy, usability, scalability)

    • Implementation complexity and timeline impact

  2. Team reviews proposals and votes

  3. If no majority reached, current Scrum Master makes final decision based on:

    • Available expertise on team

    • Time remaining in sprint/semester

Conflict Resolution Framework

Conflict Types & Resolution Paths

Technical Conflict

Symptoms: Extended debate over architecture, technology choices, API design, database schema

Resolution (48 hours):

Commitment Conflict

Symptoms: Missed deadlines, incomplete tasks, unresponsiveness, “ghosting”

Resolution (48 hours):

  1. Scrum Master(or the person blocked) initiates private one-on-one conversation

  2. Use “I” statements focusing on impact:

    • Wrong: “You never finish your code on time”

    • Right: “I’m blocked on frontend work because the API endpoints aren’t ready. Can we discuss what’s preventing progress?”

  3. Identify root cause:

    • Overload from other classes → redistribute tasks

    • Technical difficulty → schedule pair programming

    • Unclear requirements → clarify and document

    • Personal issues → adjust sprint commitments realistically

3-Day Rule: If team member is unresponsive for 3 consecutive days without prior notice, trigger professor escalation.

Structural Conflict

Symptoms: Task overlap, unclear ownership, duplicated work, integration failures

Resolution (Immediate Meeting within 24 hours):

  1. Stop current work and schedule 30-minute meeting

  2. Review and update:

    • GitHub project board assignments

    • Definition of Done for each role

    • API contracts and integration points

  3. Document decisions in the docs repository

  4. Redistribute work to eliminate overlap

Interpersonal Conflict

Symptoms: Passive-aggressive comments, tension in meetings, communication breakdown

Resolution (48-hours):

  1. Address directly but privately within 48 hours (don’t let it fester)

  2. Use non-judgmental language focused on behavior impact:

    • Wrong: “You’re always dismissive in code reviews”

    • Right: “When my PRs receive comments like ‘this won’t work” without explanation, I feel my approach isn’t being considered. Can we discuss the technical tradeoffs more thoroughly?”

  3. If unresolved after private conversation, Scrum Master mediates

  4. If mediation fails, trigger professor escalation

  5. For harassment or ethics violations, escalate immediately (no 48-hour wait)

Professor Escalation Protocol

When to Escalate (Point of No Return)

Immediate Escalation (within 24 hours):

Escalation Within 48 Hours:

Escalation Format:

Email to professor with subject: [CAPSTONE ESCALATION] Brief Description

Body should include:

  1. Context: What conflict occurred and when it started

  2. Resolution Attempts: What we tried internally (reference specific charter sections)

  3. Current Impact: How this affects project timeline, deliverables, and team function

  4. Request: Specific help needed (mediation, deadline adjustment, requirement clarification)

Sprint Tracking & Health Monitoring

RAG Status Assessment

At end of every backlog refinement, team assigns project health status:

Green: On track

Amber: At risk (action plan required)

Red: Critical (escalation required)

Action: If Red status persists for 2 consecutive sprints, automatic professor escalation.

GitHub Project Board Structure

Columns:

  1. Backlog (prioritized, not yet refined)

  2. Ready (refined with acceptance criteria, can be started)

  3. In Progress (assigned, actively being worked)

  4. In Review (PR open, awaiting approval)

  5. Done (merged to main, documented)

Required Labels:

Board Maintenance:

Decision-Making Framework (GIST)

For proposing new features, technical approaches, or scope changes:

Goal: What problem are we solving? How does this align with zero-knowledge student verification and project success criteria?

Ideas: What are 2-3 alternative approaches? What are the tradeoffs?

Step-Project: What’s the smallest version we can build to validate this idea? Can we prototype in one sprint?

Tasks: Break down into implementable units (<8 hours each) with clear acceptance criteria.

Post-Conflict Protocol

After any conflict resolution:

  1. Update Processes: If conflict revealed gap in this charter, propose amendment via PR

  2. Reset RAG Status: Move from Red → Amber or Amber → Green with documented recovery plan

  3. Blameless Retrospective: In next sprint retro, discuss what we learned as a system failure, not individual failure

  4. Move Forward: Once resolved, discussion is closed-focus returns entirely to code and deliverables

Forgiveness Clause: Capstone is high-pressure and runs concurrently with other demanding coursework. We acknowledge stress happens, extract lessons from conflicts, and do not hold grudges. Every sprint is a fresh start.

Charter Amendments

Process:

  1. Any team member can propose amendment via PR

  2. Discuss in next scheduled team meeting

  3. Requires 4 out of 5 votes to adopt

  4. Version number increments, change log updated

Winter is coming. So is the deadline. Critique code, not teammates.
The North remembers. So does your Git history. Be kind.

Signatures

By signing below, all team members acknowledge they have read, understood, and agree to abide by the terms outlined in this Team Charter.

[TABLE]