Upstream target selection

Start from your own workarounds

Every place you routed around a missed optimisation is a candidate: the linalg.generic that refused to vectorise, the transfer that scalarised, the dynamic shape that failed to compile, the fallback you added to keep the table honest. You already have the input that shows the limitation, which is most of a bug report.

Three filters

Reproducible in under twenty lines. Fixable in one place, ideally one pattern in one file. Somebody else has the same problem: an open issue, a TODO in the source that names your case, or documented behaviour the code does not deliver. A target that passes all three is a patch. One that passes two is a project, and this phase has no room for a project.

Size it

A fifty to two hundred line diff lands. A new pass does not, and neither does a rewrite of a lowering that already has tests. If the fix needs a new abstraction, it is a series, and the first patch must be the smallest one that changes behaviour.

Name the mechanism

Before touching code, write the target as one sentence with three parts: the pass, the case, the mechanism. “<pass> mishandles <case>; <mechanism> is where it should be handled.” If the sentence will not close, the target is still a symptom. Then read the issue tracker and the last month of commits on the file you would touch, because a target fixed last week is the commonest wasted fortnight.

Things that break

The cosmetic pull request, a typo or a renamed test, which merges and signals that you did not find anything real. The two-thousand-line feature still in review when the plan ends. And a target in a project you have never built, where every iteration costs a full build before you can test the sentence you wrote.