Project Guide

Project gates

The gates are checkpoints in one continuous build. Each should show what changed because of evidence, feedback, or evaluation—not just that the team produced more features.

Exact due dates, submission instructions, and grading appear in Canvas, which is authoritative.

Team charter

Submit a short charter with Gate 1. It should record:

• regular meeting and working times;
• the team’s normal response-time expectation and how to flag something urgent;
• how product and technical decisions will be made;
• how code review, branches, deployment access, credentials, and documentation will work;
• initial ownership and a plan for rotating or sharing less visible work;
• what the team will do when someone is blocked or misses a commitment.

The charter is a working agreement, not a contract frozen in Week 4. Revisit it after Gate 2 or whenever the team’s needs change.

Sharing the work

Divide work into meaningful vertical slices rather than an assembly line. Each member should own work that connects a user or product question to implementation, evaluation, and explanation. Avoid arrangements in which one person only builds the interface, one only writes prompts, one only evaluates, and one only writes the report.

Some specialization is natural, but every member should understand the whole system, review teammates’ work, and be able to explain the main product and evaluation decisions.

Individual contribution and grading

Project grades are individual, not purely team-based, so students on the same project may receive different scores. The teaching team considers multiple forms of evidence:

• confidential peer feedback, including a mid-project pulse and final peer evaluation;
• the team charter and subsequent ownership decisions;
• project artifacts such as research notes, decision records, evaluation work, code, design, and writing;
• conversations with the team and each member’s ability to explain and defend the work;
• repository history where it provides useful context.

Commit counts and lines of code are not contribution scores. Research, user testing, evaluation design, product judgment, coordination, and careful review may be just as important as implementation.

Getting help early

Do not wait for the final peer evaluation to reveal a serious team problem. Start by naming the issue concretely and revisiting the charter. If that does not resolve it—or if raising it directly feels unsafe or inappropriate—contact your assigned mentor in the private team Slack channel or contact the teaching team privately. We can clarify responsibilities, facilitate a reset, adjust scope, or discuss changes to the team.

Tell us promptly if a teammate withdraws, has an extended absence, loses access to essential tools, or is consistently unable to participate. Early communication gives us more ways to help without derailing the project.

Demo Day and public release

Demo Day is public, though the expected audience is the class and invited guests. A team should assume that anyone may see what appears on screen. Do not display secrets, private user information, restricted data, or material the team is not authorized to share. Use synthetic or de-identified demonstration data when appropriate.

An audience member may not record or redistribute a presentation without the team’s permission. Any official recording will be opt-in by team.

Project repositories remain private throughout the course. After final submission, a team may release its repository only with unanimous agreement and after completing the privacy, rights, attribution, and credential checks in Privacy, recording, and public work.

A live technical failure is not itself a failed project. Teams should prepare a short fallback—such as a recorded run, screenshots, or saved outputs—and be ready to explain what failed and what evidence supports the intended behavior.

Responsible development

Projects involving sensitive data, real external communities, consequential decisions, or agents that can act in the world require advance discussion with the teaching team. Read the full responsible product development policy before user testing or deployment.

Starter Projects

Some example project ideas teams may pick from or adapt. Each is scoped to a 7-week build and teaches a distinct evaluation lesson.