Presenting your work · Ground Truth

Make a reviewer's first two minutes count. These are presentation suggestions, not measured hiring effects:

Archive the tutorial forks. A weak repository sits next to your strong one and gets opened too. Make your strongest projects easy to find.
Make the README useful without running the code. State the question, the result with a number, the architecture, the key decisions, what did not work, and the known failures. Those last two sections show a reviewer your judgement.
Show something working. Offer a public demo, recorded walkthrough or reproducible local command that suits the data and cost.
Write things up. One short post per major topic, explaining it plainly. It is good revision, and it is how people find you.

A README outline that works. Copy this into each project and fill in the blanks:

# [Project name]

## Question

One sentence: what did you try to answer?

## Result

State the baseline, result, held-out sample size and uncertainty.
Say whether the evidence is synthetic, retrospective or from a live experiment.

## How it works

Three to five sentences, or a simple diagram. Link a live URL if you have one.

## Key decisions

Two or three bullets: what you chose and what you rejected.

## What did not work

One or two failures, with evidence and what you changed.

## Operations evidence

If it is deployed: release manifest, the alerts you act on, cost per 1k requests, and a link to
the incident report from a deliberate failure.

## Known limitations

What the system should not be used for.

For the operations section, link your Chapter 6 artifacts directly: the incident report, rollback runbook, cost table and model card. The reference lab has filled, simulated examples of a model card and an incident rehearsal. Use them as formats, not as your evidence.

A business project can use the Chapter 9 evidence levels. "Improved policy value in a simulator" and "increased live contribution in a randomised test" are different results. Include the assignment unit, horizon, no-action baseline and costs. If you only have observational transactions, show predictive performance and say what intervention evidence is missing. A reviewer should be able to reproduce the claim you actually make.

Try it yourself. A README's Result section says: "Churn model achieves 94% accuracy and will save the business $200k a year." What would a reviewer object to, and how would you rewrite it?

Hint and explained answer

Ask what the baseline is and what links a prediction to money. If 6% of customers churn, predicting that nobody leaves is also 94% accurate, so the number says nothing on its own. The savings figure needs a retention effect, which a churn classifier does not estimate. A checkable version names the baseline, the held-out cohort and its size, a decision metric with an interval, and the evidence level: "On a later cohort of 2,000 customers (6% churned), precision among the 100 we can contact was 0.31 against 0.18 for a recency rule, with a paired bootstrap interval for the difference. Retrospective evidence only. Savings need the proposed randomised retention test."

For open source, start with a bug you hit while building your own project. The entries in Chapter 7's resources cover the mechanics. Read each project's current contribution policy. scikit-learn requires contextual understanding, careful human review and disclosure of AI tool use. Transformers welcomes coordinated, verified AI assistance and requires disclosure and test evidence. You stay responsible for every changed line and for the maintainers' review burden.