Which bug report opening is most useful to a maintainer?
Effective bug report titles/openings: name the specific endpoint or function, describe the exact symptom (HTTP 500), specify the trigger condition (Unicode username), and note what works (ASCII). A maintainer reading this knows immediately what is broken, where to look, and what to test. "Broken", "bug found", and "something wrong" tell the maintainer nothing actionable.
2 / 10
What does "steps to reproduce" mean in a bug report, and which example is correct?
Steps to reproduce must be: numbered, exact (include the precise request, input, or action), complete (starting from a clean state), and deterministic (reproducible by someone with no knowledge of your specific setup). A maintainer should be able to follow the steps and see the same bug without any guesswork.
3 / 10
A bug report template asks for "Expected behaviour" and "Actual behaviour". Which pair is most useful?
The expected/actual pair should be specific enough that a maintainer can write a failing test from it. Include: the exact HTTP method and path, status code, response body, and any relevant log output. "It should work" vs "it does not work" gives zero information for debugging. The log snippet in the actual behaviour is especially valuable — it often reveals the root cause immediately.
4 / 10
The bug report template asks for "Environment". Which response is most useful?
Environment details help maintainers reproduce and isolate bugs. Include: OS + version, runtime + version, package version (exact — not "latest"), execution context (browser/server), and environments tested. "My computer" and "Windows" are too vague. "Latest version" is actively harmful — maintainers need to know whether the bug exists in the version they just released.
5 / 10
You are reporting a bug in an open source library. You have not investigated the root cause but you have a reliable reproduction. Which statement best describes your responsibility?
A reliable reproduction is the most valuable thing a bug reporter can provide. Many maintainers say "a reproducible bug report is already 80% of the fix." Root cause analysis and fixes are welcome additions but are not prerequisites. Demanding that reporters fix bugs before filing them is a community anti-pattern that reduces bug reporting and leaves maintainers without visibility into real-world issues.
6 / 10
Liam, a junior developer, submits a bug report for the Phoenix API. He writes: 'The API returns an error when I send a request with no authorization header. This happens consistently.' Which of the following is the MOST helpful addition to this report?
The original report is too vague. While it describes the *what* (an error), it doesn't provide enough information for someone to quickly understand and reproduce the problem. Option A highlights this deficiency – a good bug report needs precise details like the API endpoint being called and the request structure. Options B, C, and D all miss this crucial element of clarity.
7 / 10
Sarah is reviewing a pull request for a new feature in the Nova framework. The PR contains a bug report stating: 'Button click does not trigger action.' Sarah asks Mark to provide more detail. Which of the following questions would be MOST effective for Mark to answer?
The bug report's statement 'Button click does not trigger action' is extremely open to interpretation. Mark needs to elicit specific steps – the exact sequence of events leading up to the problem. Options A and B are too vague; C focuses on versioning which isn't immediately relevant, and D provides a visual aid that doesn't address the core issue of understanding the reproduction steps.
8 / 10
David is drafting a bug report for a problem with the Zephyr messaging service. He includes the following in his description: 'The message queue is slow.' What additional information should David include to make this report more effective?
The statement 'The message queue is slow' is subjective and lacks crucial context. David needs to quantify the problem by providing specific examples – measuring delay times with timestamps and identifying affected queues. Options A, B, and C are irrelevant or simply provide circumstantial evidence without addressing the core issue of performance degradation.
9 / 10
Emily is responding to a Slack message from a colleague regarding a bug she's reporting. The colleague asks: 'Can you give us the steps to reproduce this?' Emily replies: 'It just happens when I try to save.' What should Emily do NEXT?
The colleague is requesting clear steps to reproduce. 'It just happens when I try to save' offers no actionable information. Emily must translate this vague description into a series of specific actions – what button was clicked, which data was entered, and the order in which these steps were performed. This directly addresses the need for reproducible steps.
10 / 10
Ben is submitting a bug report for an issue found during automated testing of the Orion database service. The report states: 'Database connection refused.' Which of the following should Ben *NOT* include in his report?
While providing environmental details is helpful for debugging, including the application server configuration (AWS EC2 instance type) is generally irrelevant to a database connection refused error. The problem likely resides with the database itself or network connectivity. Options A, B and D are all valuable pieces of information that would aid in diagnosing and reproducing the issue.
This module focuses on Open Source Contribution — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Open Source Contribution exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around open source contribution — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Open Source Contribution exercises?
See the Open Source Contribution hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.