Skip to content

Team Charter

Submission
Team
Due
Fall, week 2
Weight
4% of the fall grade

Winter’s charter refresh is part of the first Repo Checkpoint of the term, and spring’s closes the Team Health Assessment workshop in week 2; neither is a separate assignment.

Every functioning engineering team runs on an agreement about how it works, whether or not anyone wrote it down. Teams that write it down early move faster, argue better, and survive their first bad week. Teams that do not spend winter discovering their agreement by collision. The charter is that agreement: short, specific, and written before you need it.

The charter lives in your repository as docs/charter.md. Git history is the change log; there is no separate revision table to maintain. When the charter changes (and it should, as your retrospectives teach you things), change the file and commit.

Three artifacts, all in the repository:

  1. docs/charter.md: the charter itself, 2 to 4 pages of focused, scannable policy (sections below).
  2. CONTRIBUTING.md: setup steps a new contributor can follow, local commands for tests and linting, the branch and PR workflow, code review expectations, and where to ask for help. Start from the CONTRIBUTING template.
  3. The AI context file (AGENTS.md, CLAUDE.md, or your tooling’s equivalent): project context, conventions, and constraints your AI tools should know. If your docs are good, this file mostly points at them. AGENTS.md is the cross-tool convention and the safest default on a team where people use different tools; per-tool files should point at it rather than duplicate it.

Submit the repository link on Canvas. NDA teams submit a PDF export of all three files.

Name who holds each of the three rotating roles and when rotation happens (at minimum, once per term). These three names are the ones the defense asks about; do not rename them in your charter:

  • Project Manager (PM): owns the board and the partner communication cadence; owes the team an honest view of where the sprint actually stands.
  • AI Coordinator: owns the AI context file and the confidentiality boundary; owes the team current tooling guidance and a working answer to “can I paste this into that?”
  • Quality Owner: owns CI health, the Definition of Done, and releases; owes the team a repository that is always one honest step from demoable.

State what each role owes the team in your own words. A new member should be able to read this section and know who to ask about what.

Commit to a rotation such that every student chairs at least one decision per term and holds a named role or comparable ownership area at least once across the year. Chairing means driving a decision to a conclusion, not merely having an opinion in the thread. Record who chaired what in each sprint note; that record is what the defense role criterion is checked against.

How choices are proposed, decided, and escalated: your decision rule (consent, majority, PM tie-break), where decisions get recorded (see the ADR guide), and at least one explicit escalation or override rule for when you are stuck.

Meeting times, communication channels, and core tools, including where decisions and notes live so an absent teammate can catch up without asking.

A restorative, stepwise conflict path: name it early, talk directly, involve the team, escalate to staff, with time bounds and measurable triggers (missed meetings, unreviewed PR backlog). Accountability ties to observable evidence (PRs, reviews, attendance), not testimony. The Working Agreement guide has patterns that work; steal them.

The checks a change must pass before it merges: tests, review, docs updated, lint and security checks, and the CI gates that enforce them. Point at the actual CI configuration; a Definition of Done that nothing enforces is a wish.

Meeting norms that let everyone contribute (time zones, note-taking, turn-taking), how a teammate requests an accommodation, and how the team surfaces barriers without drama.

Every student owns at least one reviewed pull request per sprint. Record how your team makes that workable (sizing, pairing, review turnaround expectations). This norm feeds the individual contribution modifier on Sprint Notes, so write it as something you will actually follow.

One page stating which data, code, and documents may enter which AI tools, per your partner agreement: what is fully open, what may go only into approved or local tools, and what never leaves the repository. Cover code, partner data, credentials, and meeting content. See the Generative AI guide.

Criterion Points Outcome
Roles: three named rotating roles with a rotation schedule, a clear decision process, and what each role owes the team 20 SO5
Conflict and inclusion: restorative stepwise path with measurable triggers, evidence-based accountability, and concrete inclusion norms 15 SO5
Cadence and tools: meetings, channels, and where decisions are recorded, unambiguous 10 SO3
Definition of Done: specific checks tied to CI gates that actually exist 15 SO2
CONTRIBUTING.md and AI context file: published, complete, and followable, including the PR-per-sprint norm and review expectations 15 SO3
AI and confidentiality one-pager: explicit about which data and code may enter which tools, consistent with the partner agreement 15 SO4
Writing: 2 to 4 pages, headed by the required sections, and every commitment a single sentence a teammate could quote back 10 SO3

AI use: AI may draft any of this; the agreement must be yours. A charter your team has not actually agreed to is worse than none, because it tells you nothing when you need it.

Set Up Your Repository’s Skills covers both the AI context file and the confidentiality one-pager; do it in week 1. Beyond that: Assess Your Team’s Conflict Styles for conflict and inclusion, and Responsibility Assignment Matrix (RACI) for the roles criterion.

Browse teamwork and conflict resolution when these run out.