A useful report supplies that path. Write the starting state, exact steps, expected result and actual observation separately. Leave the cause open until someone has evidence for it.
The worked report below uses a deliberately faulty meeting-list teaching demo. It is fictional, self-contained, and separate from NOS product behavior.

Start with a report someone can follow
The supplied teaching scenario has three sample meetings:
| Sample ID | Meeting | Supplied grouping |
|---|---|---|
| M1 | Planning check-in | Today |
| M2 | Archive review | Later |
| M3 | Volunteer briefing | Later |
“Today” is a fixed sample label. It does not use your device's date or a real calendar.
Build DEMO-A is designed to show a mismatch after selecting Today, then All: the heading returns to “All meetings,” while the list retains M1. The expected full list is M1, M2 and M3.
Here is a completed report of that supplied scenario. It is a model of the report wording, not a claim that a production defect or a test run occurred. When you run the example, check the actual result and record your own environment and attempt count.
Worked bug report
Title: DEMO-A: selecting All after Today leaves only M1 under “All meetings”
Affected artifact: The deliberately faulty local meeting-list teaching demo, build DEMO-A. No production application or customer account is involved.
Environment: Browser, browser version, operating system and actual run date: TO CONFIRM from the person reproducing it.
Starting state: Reset the sample. “All meetings” is the heading and all three sample rows—M1, M2 and M3—are visible.
Steps:
- Select Today.
- Check that the heading is “Today meetings” and only M1 is visible.
- Select All.
- Compare the heading and visible row IDs.
Expected result: “All meetings” with M1, M2 and M3 visible, because All should restore the complete supplied sample list.
Actual result in the supplied scenario: “All meetings” with only M1 visible. Replace this entry with what you actually observe if your run differs.
Reproducibility: TO CONFIRM. Record attempts and matching results after running the steps; do not turn one example into “always happens.”
Observed scope: The scenario concerns this filter sequence in this sample. Other sequences, browsers and applications are not established.
Evidence: The self-contained teaching page and the exact sample IDs above. Attach your own safe capture of the resulting state if needed. No screenshot, console error or stack trace is supplied as evidence here.
Cause and fix status: Unknown. The report does not establish a production cause, owner, fix or verified resolution.
This report gives the next person a starting state and a visible comparison. It also gives them room to say, “I followed those steps and saw a different result.”
Make the title describe the divergence
A short title can hold the trigger and symptom:
DEMO-A: selecting All after Today leaves only M1 under “All meetings”
That is more useful than:
All is broken because the database cache is stale
The second version guesses a cause. Nothing in the report establishes a database, a cache, or a fault in either one.
Firefox's guidance on filing good bugs emphasizes an actionable description, precise reproduction information and enough context to investigate. Its project-specific labels and contribution process do not need to become part of your team's template.
Keep expected and actual results independent
The expected result needs a basis: a supplied requirement, agreed behavior, or an explanation someone can check. Here, All means the full three-row sample set.
The actual result is what the reporter observed after the stated steps. It should not repeat the expectation with “failed” added.
For a real report, write the visible label and IDs, counts, values or error text that matter. If a capture shows a different state from the report, resolve that mismatch before handing it over.
Record uncertainty at the relevant field. “Browser version TO CONFIRM” is a specific missing detail. A guessed version makes the report look complete while making reproduction less reliable.
Copy the blank report
BUG REPORT
Title — trigger and visible symptom:
Affected application/page and build:
Environment:
Browser and version:
Operating system:
Actual observation date:
Starting state and permitted sample data:
Exact minimal steps:
1.
2.
3.
Expected result:
Basis for that expectation:
Actual observed result:
Visible text, row IDs, count or error:
Reproducibility:
Attempts made:
Matching results:
Conditions not yet checked:
Observed scope and practical impact:
Keep untested scope and impact unknown.
Safe evidence:
Reproduction page or permitted reference:
Capture/log from this actual observation, if available:
Unknowns and follow-up questions:
Cause:
Fix status:
Describe impact at the scale you observed. A sample row missing from this demo does not establish customer loss, production severity or a broad outage.
A prompt for preparing the report and a small reproducer
Use a safe, minimal example you are allowed to share. Do not paste credentials, personal records or private production logs into the prompt.
Help me prepare an actionable bug report.
Affected artifact and build: [PASTE]
Actual environment and observation date: [PASTE OR TO CONFIRM]
Starting state and permitted sample data: [PASTE]
Exact actions I performed: [PASTE]
Expected behavior and its basis: [PASTE]
Actual observed behavior: [PASTE]
Attempts and matching results: [PASTE OR TO CONFIRM]
Safe evidence I actually have: [PASTE OR NONE]
Unknowns: [PASTE]
Write a concise trigger-and-symptom title, starting state,
numbered minimal steps, expected result, separate actual result,
environment, reproducibility, observed scope, safe evidence and
unresolved questions. Preserve uncertainty. Do not invent a cause,
browser/version, run, frequency, screenshot, stack trace, impact,
issue ID, owner or fix.
Separately create one complete self-contained HTML teaching page
using this explicitly fictional meeting-list fixture:
Build DEMO-A, deliberately faulty; not a defect in NOS.
M1 Planning check-in: Today.
M2 Archive review: Later.
M3 Volunteer briefing: Later.
Today is a fixed sample grouping, not the device's current date.
Start with All meetings and all three rows. Today changes the
heading to Today meetings and displays only M1. Deliberately make
All restore the All meetings heading without restoring rows.
Reset sample restores the full initial state. Show the supplied
expected outcome beside the current visible outcome. Do not
claim this is a production incident or a diagnosis.
Include the worked scenario report and a vague-message comparison.
Label the report as supplied teaching content; do not claim an
actual run or environment. Add separate temporary fields for the
reader's environment, actual result, attempts and safe evidence
notes. Preserve them while using the sample. Ask before clearing
those notes; cancel retains them, confirmed clear leaves the
sample state unchanged.
Use native keyboard-accessible buttons and visible focus. Text
at least 16px; readable at 360px without horizontal page scrolling.
Inline CSS/JavaScript only, no external assets/network/storage,
no tracker submission or fake export. User typing stays text.
Return the full HTML and a list of details requiring a real run.
Run the resulting page before treating its behavior as evidence. If the sample does not reproduce the described mismatch, correct the example or the report. A generated explanation of what a page should do is not an observation of what it did.
Let the next reviewer repeat the same steps
A sanitized, self-contained HTML reproduction can sit beside the report in a NOS reading copy. The reviewer can reset the sample, follow the sequence, and compare the visible state with the written steps.
If the report says only “clear the filter,” edit the static instruction to name the exact control: “Select All after selecting Today.” Repeat that sequence to check whether the clearer wording reaches the same state, then carry the correction into the team's maintained issue record.
Record the actual environment and attempts there. Keep the bug open or resolved according to your team's real investigation and verification, rather than the wording or appearance of this teaching page.