A bug tracking system is a software application that keeps track of reported software bugs in software development projects. Many bug tracking systems, such as those used by most open source software projects, allow end-users to enter bug reports directly. Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other software project management applications. A bug tracking system is usually a necessary component of a good software development infrastructure, and consistent use of a bug or issue tracking system is considered one of the "hallmarks of a good software team".
At Red Hat we say: "If it's not in Bugzilla, it's not a bug!"
Further reading: https://en.wikipedia.org/wiki/Bug_tracking_system
- Work in pairs
- Answer the question
- What information does a bug report need to include ?
Share your answers with the class. We will discuss the answers after the next exercise.
-
Work alone.
-
Fork this repo under your username in GitHub
-
Select one of the following bugs (or another at your will):
-
Nokia 700 shows wrong caller ID
-
Instructor will briefly explain what the bugs are if you have troubles spotting them
-
Create a GitHub issue inside your repository and describe the bug you have selected. Describe the bug as best as you can.
-
NOTE: Add URL link to the chosen problem in your bug report! (for reference purposes)
Instructor will examine your bug reports and explain what information is vital and really important and what information not so much.
For more information see
- Work in pairs
- Exchange URLs of your initial bug reports
- Review each-other's reports
- Make notes of the URL and what information is present (good) or missing (bad) in the bug report!
Ask instructor for help if necessary.
Share the good and bad sides of the bug report with the class.
-
Read the following articles:
-
https://github.com/blog/2111-issue-and-pull-request-templates
-
https://help.github.com/articles/helping-people-contribute-to-your-project/
-
Create an
ISSUE_TEMPLATE.mdinside your GitHub repository, containing placeholders for important bug information -
Add the Steps to reproduce or How to test sections to your template
-
Verify that the template works
-
Create a new bug report, using the template, for the same issue that you reported previously
Ask instructor for help if necessary.
- Work in pairs
- Exchange URLs of bug reports from previous exercise
- Review each-other's reports
- Make notes of the URL and what information is present (good) or missing (bad) in the bug report!
- Answer the question:
- How good is the proposed
ISSUE_TEMPLATE.md?
Ask instructor for help if necessary.
Share your findings with the class.
You have to read lots of bug reports to learn how to write a good one. Here are some examples to get you started:
- Cat sitting on keyboard crashes lightdm
- RHBZ 849090 - f18 tc3 is not stable
- atodorov'v public bug list - earlier bugs are likely badly written
TODO: more to be added
- Read through the above bugs
- Discuss in pairs why you think they are baddly written
- Discuss with the class your findings
Contribute an ISSUE_TEMPLATE.md to an open source project on GitHub.
Select one which you like or are familiar with (if possible).
Make a note of the URL of your pull request (for future reference).
You need to be at least somewhat familiar with the project so I'm not going to propose projects to work on.