WHY ENGLISH?
Turn “the app is broken” into a safe, reproducible and respectful report that helps a support or engineering team see the same problem, judge its impact and verify a repair
Writing a software bug report means naming the affected product and version, environment, starting state, steps to reproduce, expected behaviour, actual behaviour, frequency, evidence, impact, workarounds and retest result. English matters because crash, freeze, delay, incorrect result, intermittent failure, data loss and cosmetic defect describe different observations and call for different responses.
GitHub’s official issue-form example separates current behaviour, expected behaviour, steps to reproduce, environment and additional context. GitHub also explains that structured issue forms can prompt contributors for specific information. These fields are not a universal law, but they show why a report becomes more useful when a second person can follow its evidence instead of guessing what “doesn’t work” means.
This guide follows a fictional student reporting a timetable app that duplicates one lesson after a calendar import. It does not identify a real vulnerability, diagnose a root cause, authorise publication of private logs, promise a repair or replace the product’s support and security-reporting rules. If a problem involves security, personal data or immediate harm, use the organisation’s protected escalation route.
Article contents
Open all chapters
- 1. Search Before Opening a New Report
- 2. Name the Product, Version and Account Context
- 3. State the Starting Condition
- 4. Write the Smallest Ordered Steps
- 5. Describe Expected Behaviour From a Real Basis
- 6. Record Actual Behaviour Without Guessing at Cause
- 7. Measure Frequency and Scope
- 8. Attach Focused and Safe Evidence
- 9. Explain Impact and Severity Separately
- 10. Document a Safe Workaround
- 11. Respond to Clarifying Questions With Traceable Updates
- 12. Retest the Exact Claimed Fix
ORIENTATION
What this guide covers
Current fact check
Checked on 9 November 2026, GitHub Docs described issue forms as a way to request specific, structured information. Its official bug-report example included current behaviour, expected behaviour, steps to reproduce, environment and additional context, and suggested searching existing issues first. This supports a reproducible reporting structure; it does not mean every organisation uses GitHub or the same mandatory fields.
What this guide does not cover
This article owns writing, submitting, clarifying and retesting an ordinary software bug report. It does not own vulnerability disclosure, incident response, forensic analysis, root-cause analysis, product roadmaps, service-level agreements, source-code repair, legal complaints, data-breach notification, public accusations or access to confidential logs.
Worked example
Every chapter returns to a fictional polytechnic student whose timetable app duplicates a laboratory lesson after importing an updated calendar on one phone and app version. It is fictional, low-stakes and educational; it does not report a real school, clinical decision or guaranteed outcome.
Did You Know? For software bug report, precise communication makes appraisal possible but does not perform the appraisal, remove bias or guarantee transfer.
Warm up with eduKate’s guides to explaining scientific evidence and asking better questions in class.
CHAPTER 1 OF 12
1. Search Before Opening a New Report
Why this move matters
Check current documentation, service notices and existing issues using the exact message or symptom.
Did You Know? A careful search reduces duplicate work and may reveal a known workaround.
Turn a frustrating symptom into a reproducible report
Check current documentation, service notices and existing issues using the exact message or symptom. In The student finds no existing report for the duplicated laboratory lesson after calendar import., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Searching should not delay a private security or safety escalation.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Searching should not delay a private security or safety escalation. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Check current documentation, service notices and existing issues using the exact message or symptom.
- Boundary: Searching should not delay a private security or safety escalation.
- Application: The student finds no existing report for the duplicated laboratory lesson after calendar import. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Search Before Opening a New Report” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 2 OF 12
2. Name the Product, Version and Account Context
Why this move matters
Identify the app, build, device, operating system and relevant account or permission state without exposing credentials.
Did You Know? Environment words define where the observation occurred.
Turn a frustrating symptom into a reproducible report
Identify the app, build, device, operating system and relevant account or permission state without exposing credentials. In The report records app 4.8.2, Android 15 and a student account with calendar import enabled., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Do not paste passwords, session tokens, private identifiers or an entire account export.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Do not paste passwords, session tokens, private identifiers or an entire account export. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Identify the app, build, device, operating system and relevant account or permission state without exposing credentials.
- Boundary: Do not paste passwords, session tokens, private identifiers or an entire account export.
- Application: The report records app 4.8.2, Android 15 and a student account with calendar import enabled. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Name the Product, Version and Account Context” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 3 OF 12
3. State the Starting Condition
Why this move matters
Describe the data, settings and state that must exist before step one.
Did You Know? A starting state creates a shared experiment.
Turn a frustrating symptom into a reproducible report
Describe the data, settings and state that must exist before step one. In One valid timetable and one updated calendar file exist before import; no duplicate lesson is visible., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: A hidden prerequisite can make correct steps impossible to reproduce.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. A hidden prerequisite can make correct steps impossible to reproduce. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Describe the data, settings and state that must exist before step one.
- Boundary: A hidden prerequisite can make correct steps impossible to reproduce.
- Application: One valid timetable and one updated calendar file exist before import; no duplicate lesson is visible. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “State the Starting Condition” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 4 OF 12
4. Write the Smallest Ordered Steps
Why this move matters
Use numbered actions with exact labels, inputs and selections, removing unrelated activity.
Did You Know? Small ordered steps let another person follow the same route.
Turn a frustrating symptom into a reproducible report
Use numbered actions with exact labels, inputs and selections, removing unrelated activity. In Open Timetable, choose Import, select the updated file, confirm Merge and return to Monday., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Do not compress several choices into “then import it normally.”
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Do not compress several choices into “then import it normally.” A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Use numbered actions with exact labels, inputs and selections, removing unrelated activity.
- Boundary: Do not compress several choices into “then import it normally.”
- Application: Open Timetable, choose Import, select the updated file, confirm Merge and return to Monday. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Write the Smallest Ordered Steps” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 5 OF 12
5. Describe Expected Behaviour From a Real Basis
Why this move matters
State the outcome supported by the interface, requirement, prior documented behaviour or ordinary task goal.
Did You Know? A basis makes the comparison fair.
Turn a frustrating symptom into a reproducible report
State the outcome supported by the interface, requirement, prior documented behaviour or ordinary task goal. In The updated lesson replaces its earlier entry because Merge says existing matching events will be updated., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Expectation is not proof that the implementation is defective.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Expectation is not proof that the implementation is defective. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: State the outcome supported by the interface, requirement, prior documented behaviour or ordinary task goal.
- Boundary: Expectation is not proof that the implementation is defective.
- Application: The updated lesson replaces its earlier entry because Merge says existing matching events will be updated. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Describe Expected Behaviour From a Real Basis” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 6 OF 12
6. Record Actual Behaviour Without Guessing at Cause
Why this move matters
Describe visible results, exact wording, timing and persistence before suggesting a hypothesis.
Did You Know? Neutral wording keeps investigation open.
Turn a frustrating symptom into a reproducible report
Describe visible results, exact wording, timing and persistence before suggesting a hypothesis. In Two laboratory lessons appear at the same time; closing and reopening the app does not remove either., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: “The database is corrupted” is a diagnosis, not an observation.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. “The database is corrupted” is a diagnosis, not an observation. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Describe visible results, exact wording, timing and persistence before suggesting a hypothesis.
- Boundary: “The database is corrupted” is a diagnosis, not an observation.
- Application: Two laboratory lessons appear at the same time; closing and reopening the app does not remove either. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Record Actual Behaviour Without Guessing at Cause” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 7 OF 12
7. Measure Frequency and Scope
Why this move matters
Repeat only safe tests and record whether the issue occurs always, sometimes or under one condition.
Did You Know? Frequency helps triage without exaggeration.
Turn a frustrating symptom into a reproducible report
Repeat only safe tests and record whether the issue occurs always, sometimes or under one condition. In It occurs in three of three imports of the same test file but not when Replace is selected., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Repeated testing must not risk real data or violate policy.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Repeated testing must not risk real data or violate policy. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Repeat only safe tests and record whether the issue occurs always, sometimes or under one condition.
- Boundary: Repeated testing must not risk real data or violate policy.
- Application: It occurs in three of three imports of the same test file but not when Replace is selected. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Measure Frequency and Scope” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 8 OF 12
8. Attach Focused and Safe Evidence
Why this move matters
Provide a cropped screenshot, timestamp, sample file or permitted log that proves the relevant point.
Did You Know? Useful evidence is minimal, relevant and safe.
Turn a frustrating symptom into a reproducible report
Provide a cropped screenshot, timestamp, sample file or permitted log that proves the relevant point. In A redacted screenshot shows the two entries and time; a synthetic calendar file reproduces the problem., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Evidence can contain names, locations, tokens or personal schedules and must be reviewed first.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Evidence can contain names, locations, tokens or personal schedules and must be reviewed first. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Provide a cropped screenshot, timestamp, sample file or permitted log that proves the relevant point.
- Boundary: Evidence can contain names, locations, tokens or personal schedules and must be reviewed first.
- Application: A redacted screenshot shows the two entries and time; a synthetic calendar file reproduces the problem. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Attach Focused and Safe Evidence” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 9 OF 12
9. Explain Impact and Severity Separately
Why this move matters
Describe who is affected and what task is blocked, delayed or misleading, leaving formal severity labels to the defined system.
Did You Know? Impact language supports proportionate triage.
Turn a frustrating symptom into a reproducible report
Describe who is affected and what task is blocked, delayed or misleading, leaving formal severity labels to the defined system. In The duplicate can cause a student to misread a room change, but the app remains usable after deleting one entry., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Annoyance, urgency and formal severity are not interchangeable.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Annoyance, urgency and formal severity are not interchangeable. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Describe who is affected and what task is blocked, delayed or misleading, leaving formal severity labels to the defined system.
- Boundary: Annoyance, urgency and formal severity are not interchangeable.
- Application: The duplicate can cause a student to misread a room change, but the app remains usable after deleting one entry. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Explain Impact and Severity Separately” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 10 OF 12
10. Document a Safe Workaround
Why this move matters
Name a temporary route, its limits and any risk, without presenting it as the fix.
Did You Know? Clear limits help users choose responsibly.
Turn a frustrating symptom into a reproducible report
Name a temporary route, its limits and any risk, without presenting it as the fix. In Selecting Replace avoids the duplicate but removes personal notes, so the student exports a backup first., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: A workaround that loses data or weakens security is not harmless.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. A workaround that loses data or weakens security is not harmless. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Name a temporary route, its limits and any risk, without presenting it as the fix.
- Boundary: A workaround that loses data or weakens security is not harmless.
- Application: Selecting Replace avoids the duplicate but removes personal notes, so the student exports a backup first. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Document a Safe Workaround” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 11 OF 12
11. Respond to Clarifying Questions With Traceable Updates
Why this move matters
Answer in the same issue, distinguish new evidence from the original report and note changed conditions.
Did You Know? A traceable thread helps the team reason together.
Turn a frustrating symptom into a reproducible report
Answer in the same issue, distinguish new evidence from the original report and note changed conditions. In The student adds that the bug also appears on a second device using the same test file., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: Do not silently rewrite history when a material detail changes.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. Do not silently rewrite history when a material detail changes. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Answer in the same issue, distinguish new evidence from the original report and note changed conditions.
- Boundary: Do not silently rewrite history when a material detail changes.
- Application: The student adds that the bug also appears on a second device using the same test file. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Respond to Clarifying Questions With Traceable Updates” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
CHAPTER 12 OF 12
12. Retest the Exact Claimed Fix
Why this move matters
Use the stated fixed version, original steps and a small regression check, then report pass, fail or partial result.
Did You Know? Retesting closes the evidence loop.
Turn a frustrating symptom into a reproducible report
Use the stated fixed version, original steps and a small regression check, then report pass, fail or partial result. In Version 4.8.3 no longer duplicates the lesson in five imports, while notes remain intact., identify the affected product, version, environment, starting state and smallest reliable sequence before proposing a cause.
Separate what happened from what should have happened
Quote exact messages, describe visible results and state the expected result from a requirement or normal workflow. Keep this boundary: One successful test cannot prove all environments are safe.
Attach evidence that helps without exposing secrets
Use focused screenshots, timestamps, logs or sample files only through approved channels; redact passwords, tokens, personal data and unrelated records.
Support triage, workarounds and retesting
Name impact, frequency and a safe workaround, then answer follow-up questions and retest the stated build. One successful test cannot prove all environments are safe. A clear report accelerates investigation; it cannot prove the root cause or promise a fix date.
Practical reader check
- Evidence: Use the stated fixed version, original steps and a small regression check, then report pass, fail or partial result.
- Boundary: One successful test cannot prove all environments are safe.
- Application: Version 4.8.3 no longer duplicates the lesson in five imports, while notes remain intact. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Retest the Exact Claimed Fix” by separating evidence, interpretation, decision and next action. A parent, teacher or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to classroom technology support, software testing, customer support, quality assurance, product operations, data systems, laboratory tools, internships and engineering teams without guaranteeing grades, accessibility conformance, software fixes, interoperability, adoption, approval, employment or future success.
PRACTICE LAB
Build a software bug report decision trail
Student route
- Choose one real example or official document inside this guide’s scope.
- Copy its objective and underline actor, action, context, evidence and intended decision.
- Draw the specific reasoning chain used in this article.
- Mark each step reported, inferred, contested or unknown.
- Rewrite the conclusion so it preserves the narrowest important limitation.
Parent or teacher route
Ask the learner to explain turn “the app is broken” into a safe, reproducible and respectful report that helps a support or engineering team see the same problem, judge its impact and verify a repair twice: once to a classmate and once to a method specialist. Praise a precise correction and a well-stated unknown; both show disciplined attention to evidence.
Early-career route
Create a one-page software bug report audit with source link, date checked, scope, method logic, decisive wording, contrary evidence, limit and next action. A colleague should be able to continue without guessing.
Decision rule
If a shorter explanation removes the condition that made the original claim true, it is not clearer yet. Restore the condition.
Continue with eduKate’s guides to reading course and career information and giving useful feedback in group projects.
USEFUL NEXT READING
Connect this narrow owner to its neighbour
Read the software error-message guide for a related but different reader job. Return here when the question is specifically how to turn “the app is broken” into a safe, reproducible and respectful report that helps a support or engineering team see the same problem, judge its impact and verify a repair. Use each guide for the reader task named in its heading.
For English practice across research, school and career communication, visit the Singapore English Tuition Centre learning site.
FREQUENTLY ASKED QUESTIONS
Questions students and parents often ask
How long should a bug report be?
Long enough for a second person to reproduce and judge the impact, but focused enough that the key comparison is easy to find.
Should I include a guessed cause?
Label it clearly as a hypothesis and place observations first. A reporter rarely has complete system evidence.
Can I attach screenshots or logs?
Only after checking the product’s route and removing credentials, personal data and unrelated information.
Is severity the same as urgency?
No. Use the organisation’s definitions; describe impact and frequency in plain evidence.
What if the bug is intermittent?
Record the number of attempts, conditions and timestamps rather than claiming it always happens.
Does a clear report guarantee a fix?
No. It improves triage and investigation, while prioritisation and release decisions depend on wider evidence.
PRIMARY SOURCES
Read the primary guidance for this software bug report
Facts were checked against current official and primary sources on 9 November 2026. Follow the live source for later corrections, completed updates or companion material.
- GitHub Docs issue-form syntax
- GitHub Docs issue templates
- eduKate software error-message guide
- eduKate maintenance-request guide
- eduKate knowledge-base article guide
A cheerful final note
Precise English makes turn “the app is broken” into a safe, reproducible and respectful report that helps a support or engineering team see the same problem, judge its impact and verify a repair more generous, not less. People can see how their evidence and values entered the work, where disagreement remains and what a responsible next step looks like.