Last spring a small team trained an image model to sort photos of shelf stock, and for two weeks it behaved beautifully. Then it started labelling every cardboard box as “unknown”. One teammate posted in the shared channel: “The model is broken, any ideas?” Three people replied with three unrelated guesses, and the afternoon vanished. The fix, when it came, took ten minutes, and it only came after somebody rewrote that message. Below, the seven moves that teammate eventually made are laid out in order, so that the help you get is faster and more accurate.

Step 1: Say what you were trying to do

Begin with the goal, not the symptom. “I want the model to sort shelf photos into six stock categories” tells a reader what success looks like. Without it, nobody can tell whether “unknown” is a bug, a threshold or exactly the intended behaviour for something the model has never seen.

Keep it to a sentence. If the goal needs a paragraph, the problem is probably two problems, and you will get better help by asking about them separately.

Step 2: Describe what you already tried

This is the step beginners skip, and it is the one experienced helpers value most. List what you changed and what you checked: you re-ran the same photo, you tried a different image size, you confirmed the labels file had not moved. Each item removes a whole branch of guesses.

The story continues here. When the teammate wrote, “I re-ran last week’s photos and they still classify correctly, so the model file is unchanged,” the conversation shifted at once. If last week’s photos still worked, the model was fine and the new photos were different. That one sentence turned a mystery into a comparison.

Step 3: State what you expected

Expectation is the reference point for the problem. “I expected a confidence above 0.8 on cardboard, since earlier boxes scored in that range” gives a helper something measurable. If you only say the output is wrong, they have to infer what right looks like, and their inference may not match yours.

For readers new to the field, a short refresher on how classifiers read images, such as this plain-spoken primer on how machines interpret pictures, makes it easier to phrase expectations in terms a helper will recognise.

Step 4: Report what actually happened

Be literal. Paste the exact message or the exact output, not a paraphrase. “It gives weird results” is a mood; “every box scores between 0.31 and 0.38 and falls under the 0.5 cutoff” is evidence. If there is an error, copy it in full rather than the part you think matters, because the line you skipped is often the one a helper needs.

In our story, the useful detail turned out to be the numbers. Scores were not random; they were uniformly low. That pattern suggested the inputs had changed shape, not that the model had forgotten anything.

Step 5: Shrink it to the smallest example

Now do the hard part: cut the problem down until only the necessary pieces remain. Instead of the whole pipeline, share one image, one command and one output. If you can reproduce the issue with a single photo, anyone can try it on their own machine and tell you what they see.

1. Pick one input that fails.
2. Remove every step that is not needed to make it fail.
3. Confirm it still fails on its own.
4. Write down the exact steps to run it again.

The teammate picked a single box photo, ran it through the bare model with no preprocessing, and still saw the low scores. Then she tried last week’s photo the same way and saw high ones. Comparing the two files side by side revealed the new batch came from a different camera setting that saved much larger images, which the pipeline silently squeezed. Nobody had to guess any longer.

Step 6: Say what kind of answer you need

Tell readers whether you want a diagnosis, a pointer to documentation or a second pair of eyes on your reasoning. “I am not asking you to fix it, I just want to know if I am looking in the right place” is a request people are glad to meet. It also keeps replies short and on topic.

Step 7: Put it together

Here is how the rewritten message read, trimmed slightly. “Goal: sort shelf photos into six categories. Problem: since Monday every cardboard box is labelled unknown. I re-ran last week’s photos and they still pass, so the model file looks unchanged. I expected a confidence above 0.8. I am getting 0.31 to 0.38 on the new images. Smallest case: one new photo and one old photo, both run through the bare model with no preprocessing, attached. Could the image size be the difference?” Notice what is absent: no complaint, no apology, no guesses presented as facts.

That message received a correct answer within minutes, from someone who had hit the same thing before. Clear questions are respectful of other people’s time, and people respond to that.

Where to practise the habit

You can practise on your own team’s channel, but it also helps to see how others do it. One public site worth a look is Debug School, a place where practitioners and students write about DevOps, SRE and related operations work. Reading how members frame a problem teaches you the shape of a good question faster than any rule list, and the same structure suits questions about models and data.

If you are earlier in your journey and want some background on what these systems are before asking about them, an approachable introduction to neural network models is a reasonable place to build vocabulary.

A quick reference you can keep

• Goal: what you wanted the system to do.
• Tried: what you checked and changed.
• Expected: the result you thought you would see.
• Actual: the exact output, copied in full.
• Smallest case: one input, one run, one result.
• Ask: the kind of help you want.

Next time your model behaves oddly, resist the urge to type “it is broken”. Take the extra five minutes, walk through the six items, and notice how often you spot the cause yourself before you hit send. That happens more often than people admit, and it is one of the quiet rewards of asking well.