The Feature Request

Real clients change their minds. This is the closest we get in class.

How It Works

  1. Pairs are set up across menu options, so you never get to change your own app.
  2. Thursday of Week 2, your partner (the client) hands you a request on a card, in person. Pick one prompt card, and the client writes the request in one or two sentences. That's all the detail there is.
  3. Triage it in writing before you touch the code. Decide: accept, defer or decline, and why. Give a rough estimate for accepted changes.
  4. If you accept: build it, test it, and commit with a message that says what changed.
  5. If you defer or decline: say why in your README. Declining with a good reason is a valid choice.

Prompt Cards

The client picks one of these:

  • “Add a search or filter.”
  • “Export or print a summary.”
  • “Let two users keep separate data.”
  • “Add a field to every record.”

The client's job is to make the request, not to design it. If you're asked for more detail, the answer is no.

Your Response (for your README)

Copy this into your README under a heading called Feature Request.

## Feature Request

**The request:** (what the client asked for, in their words)

**Triage:** accept / defer / decline
**Why:** (the reason, in one or two sentences)
**Estimate:** (accepted only: rough time, and what it touches)

**What changed:** (the code changes, and which files or functions)

**What the tests show:** (what you tested for this change, and the results)

A good response has a decision you could defend, a request that's clear enough to test, and at least one test for the change. Keep it short: it's a paragraph or two, not an essay.

How It's Marked

The response counts toward Design process (how you respond to a change) and Collaboration (how you worked with your client). A thoughtful decline counts as much as a careful build.