A small template for useful, privacy-aware support reports

I maintain the six small projects used as examples in this note. They cover text, images, audio, reference material and measurement inputs, so they invite very different kinds of support requests.

A useful report gives a maintainer enough context to reproduce a problem while keeping private inputs under the reader's control. The examples below describe a proposed reporting format and what I would ask for in each situation.

Start with the page and the observation

Keep these fields separate:

• Page: the public tool or guide URL where the issue appears.
• Action: the smallest sequence of steps that leads to it.
• Expected: what the reader was trying to accomplish.
• Observed: the visible text, result or state they actually received.
• Context: relevant browser and operating-system versions, plus whether the issue repeats.

Copy the wording of an error when possible. If the report contains an interpretation, label it separately from the observation. “The progress message has not changed for two minutes” is an observation; identifying the underlying cause needs further evidence.

Match the requested evidence to the task

These are examples from projects I maintain. The suggested evidence is a starting point for a report, rather than a claim that any particular failure has occurred.

Example	Useful details to include
the superscript generator's character coverage notes	A short, non-sensitive sample of the input and output, the character-coverage note, and the destination app if the appearance changes after copying.
how the PokéSurvivor tier list separates opinion from in-game stats	The relevant section, the guide version or observation date, and whether the concern is a qualitative recommendation or a numerical comparison.
WatermarkPilot's rules for metadata and unsupported files	The account state, selected-file count, file formats, and the exact message. A synthetic sample image can help demonstrate a visual issue without exposing a client's photos.
Sonify, and its notes on job tracking and file expiry	The visible job stage and message, time of the attempt, and whether the report concerns a result's stated expiry. Keep private job identifiers and download links in the private support channel.
GifLoom's published limits for large GIFs	Original pixel dimensions, requested dimensions, frame information where available, and the observed result. Include byte size separately when the concern is a destination's upload limit.
Square Footage Calculator, a browser-only estimator	The exact measurement notation and units, room segments and exclusions, and any selected material allowance or package coverage. Use a small synthetic arithmetic example instead of an address or a complete floor plan.

Ask for the smallest useful sample first. A text-rendering problem may need a few characters. An image issue may be reproducible with a newly generated test image. A unit-interpretation issue may need only one measurement and its expected result.

Make a short report reusable

Here is an illustrative structure for a manually prepared report. It is a format proposal that you can adapt to your own support process:

{
  "page_url": "https://example.org/tool",
  "steps": [
    "Open the public tool page",
    "Use a small synthetic input",
    "Perform the relevant action once"
  ],
  "expected": "Describe the intended result, including units",
  "observed": "Copy the visible message or describe the result",
  "environment": {
    "browser": "Name and version",
    "operating_system": "Name and version"
  },
  "sample_kind": "synthetic",
  "repeats": "unknown",
  "attachments": []
}

The record remains useful without an attachment. If a screenshot adds necessary information, crop it to the relevant control and review it for account details, private filenames and unrelated browser tabs before sharing.

Explain the next step in the reply

A maintainer's response should make the current state clear:

1. Confirm the observation that has been reproduced, if any.
2. Identify the information still needed.
3. Give a supported workaround when one is available.
4. Say how the reader can tell whether a later fix addresses their case.

When the cause is still uncertain, retain that uncertainty. A reproducible report can establish a visible problem before anyone has established its cause.

Keep account recovery, authentication secrets and private download links in the appropriate private support channel. Public examples work best when another reader can reproduce the important detail using their own small test input.