Team Charter
Canvas is the source of truth for this term’s assignments. This page may already show changes Canvas does not have yet.
In this assignment you will write your team’s operating agreement: who owns what, how decisions get made, what has to be true before code merges, and what happens when the team isn’t working. It is due in week 2, before you have had the arguments it settles. The Working Agreement guide explains why teams write one and has patterns you can adopt; this page says what you submit.
The charter is an agreement between the people on your team, so it lives with your team’s documents, not in the repository. When it changes (and it should, as your retrospectives teach you things), update it where it lives.
What You Produce
Section titled “What You Produce”Three artifacts:
- The charter itself, 2 to 4 pages of focused, scannable policy (sections below).
CONTRIBUTING.md, in the repository, with the sections below.- The AI context file, in the repository (
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. In week 2 there may be little code for it to describe: state what the team already knows (the stack, the conventions, the confidentiality boundary) and list what gets added once code exists, with who owns adding it.AGENTS.mdis 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.
If the repository you inherit already has a CONTRIBUTING.md or an AI context file, extend that file rather than starting a new one, and keep what its previous maintainers wrote that still holds.
AI use: AI may draft any of this. Every student must have read, understood, and agreed to every commitment before the team submits it, and the instruction team will challenge any commitment the team cannot realistically keep.
Required Charter Sections
Section titled “Required Charter Sections”1. Roles
Section titled “1. Roles”Three concerns must each have exactly one named owner. The charter names the owner of each, and says 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, whatever the working agreement guide says about labels being optional. The guide is worth reading for what each of the three concerns covers:
- Project Manager (PM): owns the board and the partner communication cadence; owes the team an accurate 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’s always one step from a demo.
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.
Owners are counted per concern, not per person, so team size does not change the requirement. On a team of two, one person owns two of the three concerns and the charter names which. On a team of five, the students who hold none of the three name an ownership area instead: a subsystem, the test suite, the deployment, documentation currency, or facilitation. Every student owns something nameable.
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.
2. Decision Process
Section titled “2. Decision Process”How choices are proposed, decided, and escalated: your decision rule (consent, majority, PM tie-break), where decisions get recorded (see the ADR guide, and adr.github.io for templates), and at least one explicit escalation or override rule for when you are stuck.
3. Cadence and Tools
Section titled “3. Cadence and Tools”Meeting times, communication channels, and core tools, including where decisions and notes live so an absent teammate can catch up without asking.
4. Conflict and Accountability
Section titled “4. Conflict and Accountability”A restorative, stepwise conflict path: name it early, talk directly, involve the team, escalate to the instruction team, 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 conflict-path patterns you can adopt.
5. Inclusion Norms
Section titled “5. Inclusion Norms”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.
6. AI and Confidentiality
Section titled “6. AI and Confidentiality”State which data, code, and documents may enter which AI tools, following what your partner has stated about confidentiality: any NDA, the rules for their data, and which tools may see the code. Say what is fully open, what may go only into approved or local tools, and what never leaves the repository, covering code, partner data, credentials, and meeting content. If your partner hasn’t stated these by week 2, give the boundary you are assuming and the week your team will confirm it with them. See the Generative AI guide. This section is the team’s agreement; the parts your AI tools must follow can also go into the repository as rules, in the AI context file or your tool’s rules files.
Required in CONTRIBUTING.md
Section titled “Required in CONTRIBUTING.md”CONTRIBUTING.md is written for whoever makes the next change: a teammate, your partner’s developers, the team after you, or an AI tool. It has these sections, each specific to your repository: every command exact, every rule with its value (the branch pattern, the number of approvals, the review window). Add any section your repository needs beyond them.
- Development setup: what a contributor needs beyond the README’s quickstart, such as development dependencies, environment variables and how to get their values without committing them, and local services. Link the README for the rest rather than repeating it.
- Local checks: the commands that run the tests, the linter, and the formatter, the same ones CI runs.
- Branches and commits: the default branch, the branch naming rule, and the commit message convention, with one example of each.
- Pull requests and review: what a pull request includes, who reviews it and how many approvals it needs, how soon a review is expected, and how it merges.
- Definition of Done, below.
- Where other work lives: for each kind of work that does not land as a pull request (an issue, a design document, a ticket in your partner’s system), where it lives and who accepts it there. If all of your work lands as pull requests, say so in one line.
- Getting help: where to ask, and how soon to expect an answer.
In week 2 some commands may not exist yet; list each with the hook, CI job, or test suite that will add it.
Definition of Done
Section titled “Definition of Done”The checks a change must pass before it merges: tests, review, docs updated, lint and security checks, and the CI (continuous integration) gates that enforce them. The term comes from the Scrum Guide, which treats it as a shared commitment rather than a checklist one person holds. Point at the CI configuration, hook, or test that enforces each check. In week 2 some of them may not exist yet, because there is no code to check: name the gate you will add (a pre-commit hook, a CI job, a test suite), the sprint it lands in, and who owns it.
What You Submit
Section titled “What You Submit”Submit one PDF containing all three artifacts, with the cover Submitting Your Work describes.
Rubric
Section titled “Rubric”| Criterion | Ratings |
|---|---|
| Roles20 points | |
| Conflict and inclusion15 points | |
| Cadence and tools10 points | |
| Definition of Done15 points | |
| CONTRIBUTING.md and AI context fileThe Definition of Done is scored in its own criterion; this one scores the other required sections of CONTRIBUTING.md and the AI context file.15 points | |
| AI and confidentiality15 points | |
| Writing: length, sections, quotable commitments10 points |
Activities That Prepare This
Section titled “Activities That Prepare This”Set Up Your Repository’s Skills covers the AI context file; 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 Team and Workflow when these run out.