← All writing

When one issue is really three

Some issues sit open for months, get comments from four people, and never move. They are rarely hard. They are usually three issues wearing one title.

A compound issue cannot be finished, because finishing it means finishing all of it, and the parts have different owners, different sizes and sometimes different answers. So it waits, and every time somebody picks it up they pick up whichever part they can do, and the other parts stay.

How they form

Almost always innocently, in one of three ways.

The reporter had a session, not a problem. They sat down, hit something, worked around it, hit something else, gave up, and wrote it all up in one go because it all happened at once. The connection is temporal, not causal.

The thread wandered. The issue was one thing. Somebody commented "related: this also happens on the settings page", somebody else added a nice-to-have, and eight comments later the title describes about a third of the contents.

Somebody batched deliberately. Five small things about the same screen, filed together to be considerate about noise. Reasonable, and it works right up until two of the five turn out to be contentious and hold the other three hostage.

The test

One question: could you close half of this?

If fixing part of the issue would let you close it, it is one issue. If fixing part of it would leave the issue open and still true, it is more than one, whatever the title says.

One title, three issues

Export is broken

The CSV export times out on big reports. Also the column order is different from the on screen table which is confusing. And it would be good if you could export just the filtered rows.

A timeout, an inconsistency and a feature request. Different causes, different urgencies, and almost certainly different people. Nobody can close that, so nobody starts it.

Splitting without losing the thread

The reason people avoid splitting is that it feels like losing something, and sometimes it is. The parts arrived together for a reason, even if the reason was only that one person met all three in ten minutes. That is real information about the experience of using the thing.

So split, but keep the parent. The original issue becomes the account of what happened, with links out to the three pieces. It stays open until the pieces resolve and then closes with them.

After the split

#412 Export is broken (parent, from Dana's report on 11 Sept)

→ #413 CSV export times out above ~40k rows
→ #414 CSV column order does not match the on screen table
→ #415 Export only the filtered rows (feature request)

Dana hit all three in one sitting, which is worth knowing: the workaround for #413 is what led her into #414.

That last sentence is the thing worth protecting. It is the only place the causal link is recorded, and it would have been lost by a split that just moved three bullet points into three tickets.

Who should do the splitting

Not the reporter. Asking somebody to file three issues instead of one is asking them to do triage they are not equipped for and did not volunteer for, and the usual result is that they file nothing next time.

Whoever triages should split, and then tell the reporter what happened and where their report went. That last part gets skipped constantly, and it is why people stop reporting things: not because nothing was done, but because from the outside it looks like their issue was quietly closed.

The one to leave alone

Not every multi-part issue needs splitting. If the parts share a cause, they are one issue with several symptoms, and splitting them means three people independently discovering the same root cause. The test still works: fix the cause, and could you close the whole thing? If yes, leave it together and list the symptoms in the body.

Compound and multi-symptom look identical from the title. The difference is entirely in whether there is one answer underneath, which is the sort of thing you only find out by asking.

WhatProblem asks these questions for you

It reads new GitHub issues and asks what is missing, in the issue thread, before anyone on your team has to.

Install from GitHub Marketplace