Project Handoff

Submission

Team

Due

Spring, week 10

Weight

5% of the spring grade

The last thing your team ships.

In three weeks, your team stops existing and the project keeps going: with your partner, a maintainer community, next year’s capstone team, or you. The handoff is professional knowledge transfer, and the bar is concrete: a stranger with relevant technical background can run and maintain the project using only this document and the repository. Teams that kept their living docs healthy all year will find this assignment is mostly assembly; that was the plan.

If you are keeping the project

You hold the IP by default (Projects and Teams has the details), so the successor can be your own team. Three things change: repository ownership stays with you instead of transferring, the archive declaration in section 6 still applies, and the conversation with your partner about what you are taking forward happens before week 10, not after. One thing does not change: the spring rung is scored on what shipped by week 10. “We are going to keep working on it” is the same move as “the partner will deploy it after the course ends” (see Some Truths About Shipping) and it earns the same rung.

What You Must Produce

A partner-facing handoff document (2 to 4 pages, PDF, also committed as docs/handoff.md) containing the sections below, submitted with written partner confirmation. Student-driven projects use their mentor or instructor as the confirming client. A non-responsive partner does not tank your grade: after two documented attempts, an instructor or mentor confirms instead and the criterion is scored on your documented attempts.

1. Overview and Current Status

What the project is and what problem it solves; the current deployment or delivery state (is it running, where, how stable); what is and is not included in this handoff, with reasons; and a contact for each team member for follow-up questions.

2. Setup a Stranger Can Follow

From nothing to running: prerequisites with versions, copy-pasteable install and build commands, how to run the tests, how to run a local development environment, how to deploy (or a pointer to the runbook), and the pitfalls you know about with their fixes. This should largely already exist in README.md and CONTRIBUTING.md; the handoff points at it and fills gaps rather than duplicating it. Verify it: have the team member who least knows the setup path (or your partner) execute it clean and fix what breaks.

3. Known Issues, Limitations, and Future Work

An honest, prioritized accounting: open bugs with severities (link the tracker), features that are partial or fragile, technical debt and whether it was intentional, a prioritized backlog of future work, and every credential, API key, or access permission that must be transferred, with its transfer status. “No known issues” is not a credible state for real software.

4. The Living Docs

Links into the repository’s living documentation, each confirmed current as of handoff: docs/requirements.md, docs/design.md, docs/shipped.md, and docs/risks.md, plus docs/rfcs/ for the decision record. These replace the standalone requirements and design attachments of past years; the Repo Checkpoints kept them honest, and the forward-looking section of your Project Retrospective tells the successor how to read them. See the Documentation guide.

5. Handoff Checklist and Partner Confirmation

Complete this checklist in the document; unchecked items get a reason and a follow-up plan:

• Repository access transferred to the partner, kept by the team, or archived, per agreement
• Credentials and secrets transferred securely, none committed to the repo
• Deployment environment access transferred or documented
• Open issues triaged and documented
• README.md and the living docs current and accurate
• Partner has confirmed receipt in writing

The written confirmation (quoted email or signed note, included in the document) must say the partner can access the repository, can run the project, and understands what maintaining it will take.

6. Release Consent and Archive Declaration

The school may share project archives with future students and sponsors as examples of student work; this is optional and separate from your partner’s rights to the software. Include a declaration listing every team member as Consenting or Not Consenting, note any NDA or partner restriction on sharing, and state where the project archive lives (the repository itself, or the agreed sanitized export if your project is under NDA). One dissent or restriction means the archive is not shared; the declaration is still required.

Rubric (100 points)

Criterion	Points	Outcome
Overview and status: a newcomer is oriented in half a page, exclusions and contacts explicit	15	SO3
Setup: complete, copy-pasteable, and actually verified by a fresh run	30	SO2
Known issues and future work: prioritized, severities and credential transfer covered, honest tone	20	SO6
Living docs: all four linked and current, decision record reachable	10	SO1
Checklist, written partner confirmation, and release-consent declaration all complete	25	SO4

AI use: AI may draft and assemble from your repository; that is what the living docs were for. Do not let it invent steps, links, or artifact locations: every command and URL in this document must work, because the person who discovers otherwise cannot ask you anymore.

Activities That Prepare This

Planning for Maintenance and Long-Term Support for known issues and future work, and Describe your API Reference for the living-docs criterion.

By project category:

Category	Activities
FOSS	Software Release and Versioning. Your handoff is mostly upstream already; what you owe is the state of any unmerged work
Research	Make Your Artifact Reproducible. For a research project this is the handoff: the next student has to get your numbers back
Consultancy	Planning for Maintenance and Long-Term Support. You graduate and the system stays, so for the partner the runbook largely is the product
New Product or Game	Describe your API Reference and User Manual if real users remain

Browse design and communication when these run out.