RFC (Request for Comments)

Submission

Individual

Due

Fall and winter: draft week 4, final week 8

Weight

15% of the term grade

An RFC (Request for Comments) is how engineering organizations make significant decisions in writing: someone frames the problem, lays out the options, recommends one, and invites critique before the team commits. You write one per term, in fall and winter, about a real decision your team currently faces that is hard to reverse. Not a hypothetical and not a retrospective justification of something already built: a live decision where your document should change what the team does.

Picking a decision that is actually yours

One-way doors are typically architecture, database schema, authentication and authorization, deployment topology, data migrations, licensing, and third-party commitments: undoing them costs far more than getting them right now. Most feature code is a two-way door. Telling one from the other is itself part of the exercise, and it is the judgment that matters most when much of the building is delegated.

Two situations make the choice harder, and both are ordinary:

Your partner already decided. Many teams inherit the stack, the hosting, the database, and the review process, and find out in week 3 how little is genuinely theirs to choose. Write on a decision inside that constrained space, or on how to work within a constraint you were handed: how to verify against a system you cannot change, how to migrate data on a schedule someone else owns, what you would have to prove before asking your partner to reconsider. Naming a constraint accurately and reasoning inside it is real engineering, and it argues better than an invented choice.

Nothing hard to reverse is live in your four-week window. Write on the most consequential reversible decision you face, and say in the problem framing why it is reversible and what would make it not.

Do not invent a one-way door you are not standing in front of.

What you can direct an agent or a teammate to build is bounded by how precisely you can specify it. That is the skill this assignment trains.

The Cycle

Step	When	What
Draft	End of week 4	800 to 1,500 words in fall; 1,500 to 2,500 in winter (see note below); committed to your repo under docs/rfcs/ or docs/adr/ (NDA teams submit a PDF export)
Cross-team feedback	Week 5	You give structured feedback on two drafts from other teams (pairings are generated by the staff and published in Canvas at the start of week 5); two students review yours
Revision and decision	End of week 8	Revised RFC plus a short response-to-feedback note; your team records the decision (accepted, rejected, superseded)

Start from the RFC template.

NDA teams and cross-team review

If your project is under NDA, do not hand reviewers partner-confidential context. Write the review copy of your RFC as a decision skeleton: keep the decision structure, options, tradeoff reasoning, and verification plan, and replace confidential specifics with neutral placeholders (“the partner’s internal system”, “the dataset”). If even that is not possible under your agreement, tell your TA by week 4 and staff will review your draft instead. Your AI Coordinator’s confidentiality one-pager governs what may leave the boundary.

Feedback is structured: for each draft you review, answer four questions in writing. Is the problem framed so a newcomer understands the stakes? Is any credible option missing? Would the verification plan actually detect failure? What is the single strongest improvement?

What the RFC Must Contain

1. Problem and context: what decision is needed, why now, what happens if the team does nothing.
2. Options: at least three credible options including “do nothing”, each with honest costs.
3. Analysis: the technical tradeoffs that matter (performance, complexity, maintainability, security, cost), argued from cited sources and your own project evidence, not vibes.
4. Recommendation and verification plan: what you propose and, concretely, how the team will know it worked (tests, metrics, acceptance criteria).
5. Constraints: licensing, data use, IP, and the partner confidentiality boundary as they bear on this decision.
6. Delegation and validation: what you handed to AI tools on this decision, what safety net made that reasonable (tests, CI, review gates, staging, a rollback path), and the specific points where you stopped and validated the result yourself. What is assessed is the fit between how far you delegated and how strong your net is, not how sophisticated your tooling is.

Rubric (100 points)

Criterion	Points	Outcome
Problem framing and context: a newcomer understands the decision and the stakes	15	SO1
Options: three or more credible options including “do nothing”, with honest costs	10	SO1
Technical tradeoff analysis: argued from cited sources and evidence specific to this project, acknowledges uncertainty	15	SO6, L07
Recommendation with a concrete verification plan	15	SO2
Constraints: licensing, data use, IP, confidentiality boundary addressed	10	SO4
Delegation and validation: what you handed to AI tools, the safety net that made that reasonable, and the points where you validated yourself	10	SO4
Writing: within the term’s length band (800 to 1,500 words in fall, 1,500 to 2,500 in winter), headed by the required sections in order, and every claim about the system names a file, a pull request, or a measurement	10	SO3, L08
Revision: substantive response to feedback, with a response note	10	SO3, L09
Feedback given: your written reviews of two peer drafts are specific and useful	5	SO3

Non-submission of the draft forfeits the revision points (there is nothing to revise); non-submission of peer feedback forfeits those 5 points and is visible to the affected teams. If your assigned reviewer no-shows, flag it to your TA: you will not be penalized for feedback you never received, and staff will supply a review. The standard late policy applies.

Expect written margin feedback on the draft from your two peer reviewers and rubric feedback on the final from staff.

AI use: AI may research options, draft sections, and sharpen the argument; the Delegation and validation criterion is where you say what you handed off and how you checked it. Presenting a generated analysis you did not verify as your own judgment, or inventing evidence (benchmarks, quotes, references that do not exist), fails the assignment. The defense will ask you to explain the decision without the tool.

Winter length floor

CS 462 is the writing intensive term: the winter RFC’s revised version, including the response-to-feedback note, must total at least 2,000 words. The fall RFC stays short on purpose; winter is where you go deep.

Activities That Prepare This

Different activities suit the fall and winter RFCs, so you are not redoing the same exercise twice.

Term	Activity	Criterion it serves
Fall	Map Your One-Way Doors	Choosing the topic, and problem framing
Fall	Evaluate Different Technologies	Options, and technical tradeoff analysis
Fall	Six Thinking Hats	Options, including “do nothing”
Winter	Write a Literature Review	Tradeoff analysis, and the 2,000-word source work
Winter	Proof-of-Concept	Recommendation with a verification plan
Winter	Peer Technical Design Review	Feedback given, and revision
Both	Apply the Privacy by Design Guidelines	Constraints
Both	Run a Self-Audit and an Architectural Review Pass	Delegation and validation

By project category, for finding a decision worth writing about:

Category	Activities
FOSS	Analyze a FOSS Project. Upstream conventions constrain your options hard, and an RFC that reasons accurately inside them is stronger than one that ignores them
Research	Reproduce Your Baseline and Identify Success Metrics. Which baseline and which metric are both one-way doors: change either late and every earlier result stops being comparable
Consultancy	Stakeholder Mapping and Apply the Privacy by Design Guidelines for the constraints criterion
New Product or Game	Evaluate Different Technologies and The Mom Test, which is a fast check on whether the decision matters to anyone outside the team

Browse design and creative when these run out.