The Capstone Question That Outran Its Data

Answerable version: "Among pothole requests closed within the 18-month window, is the median time to closure different across neighbourhoods, and by how much?"

Defended choices:

• Median, not mean. Response times are right-skewed (a few requests sit open for months). A mean is dominated by the tail and will make every neighbourhood look slow. Report median with the interquartile range so the reader sees spread, not just a point.
• Calendar days or business days - state it. The two give different rankings. Pick one, define it, and do not switch mid-report.
• Exclude open requests from the response-time calculation, then report their share per neighbourhood. The 22% missing closed_at is almost certainly not random - the still-open ones are plausibly the slowest, so excluding them biases every neighbourhood's median downward, and unevenly if the share varies by area. Quantify it; do not hide it.
• Minimum n. With n < 20, a median is noise. Either pool those neighbourhoods into an "other" group or show them greyed out and marked insufficient - never rank them alongside n = 400 areas.
• Boundary mismatch. Build an explicit name-to-boundary mapping table and state how many requests failed to map. Silently dropping unmapped rows loses exactly the neighbourhoods with the messiest naming.
• Unit of analysis: the request, not the neighbourhood. Weighting by population answers a different question; say which you chose.

Judgement: none of these choices changes the data - they change what you are allowed to claim from it.

Disclose:

1. This is descriptive, not causal. Slower closure in one area may reflect road type, staffing, contractor boundaries, or a backlog - none of which are in the dataset.
2. closed_at is administrative. It records when a case was closed in the system, not when the pothole was filled. Say so in one sentence.
3. Missingness is not random (22% open, direction of bias stated), plus the small-n neighbourhoods and unmapped boundary rows.
4. Reporting behaviour differs by neighbourhood. Higher-reporting areas may appear to have more problems; low-reporting areas may be under-represented rather than better served.
5. 18 months, single city - no claim about seasonality, trends, or other municipalities.

Getting a recommendation without overclaiming:

• Make the recommendation about the next measurement step, not about a proven cause: "Two neighbourhoods show a median closure time more than double the city median at n > 100; recommend the city verify with crew scheduling data before reallocating resources."
• Lead the story with the finding and its size ("a difference of X days"), put the caveats in a limitations section and one footnote, and keep the headline honest - e.g. "Closure times vary widely by neighbourhood; the gap is largest in the two areas with the highest request volume."

Judgement: the rubric rewards a recommendation, but a recommendation that outruns the evidence is the fastest way to fail the reviewer who reads the limitations section first.

Make the headline number traceable from the raw file in one path.

1. Untouched raw data plus a single script that goes raw → cleaned → analysis → chart, so a reviewer can re-run it without asking you anything.
2. A decisions log - every judgement call (median over mean, minimum n = 20, calendar vs business days, boundary mapping rule, how unmapped rows were handled) with a one-line reason. This is the section reviewers actually read; it demonstrates analysis rather than tool use.
3. A data dictionary and mapping table committed as versioned files, not pasted into prose.
4. Environment notes: package versions, data download date and URL, because open data portals revise their files.
5. A reconciliation/QA appendix: raw row count → filtered row count → rows in the final chart, with every exclusion explained. If those numbers do not add up, the reviewer assumes nothing else does.
6. The chart itself follows the same standard: units, denominator, n per group, and the date range on the figure.

Why it matters: anyone can produce a chart from a 96,000-row CSV. The credibility comes from showing that the fifty judgement calls between the CSV and the chart were made deliberately - which is also exactly what a hiring manager is testing for.