Intro to Bug Trackers (Activity)
(Difference between revisions)
Heidi.ellis (Talk | contribs) (Created page with "== Bug Trackers == === Preparation: === {| border="1" |- |'''Description''' || Learners will gain an understanding of the features of bug trackers and how they are used to ...") |
Heidi.ellis (Talk | contribs) (→Part 2 - Reports) |
||
| Line 56: | Line 56: | ||
# Repeat the previous step with a different kind of bug. | # Repeat the previous step with a different kind of bug. | ||
| − | == Part 2 - Reports == | + | == Part 2 - Collective Reports == |
# Click on the “Reports” link on the top of the page. | # Click on the “Reports” link on the top of the page. | ||
# How many bug reports were opened in the last week? How many were closed? | # How many bug reports were opened in the last week? How many were closed? | ||
Revision as of 22:26, 7 April 2013
Contents |
Bug Trackers
Preparation:
| Description | Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project. |
| Source | None. |
| Prerequisite Knowledge | None. |
| Estimated Time to Completion | 60 minutes |
| Learning Objectives | Ability to: 1) Describe the role that a bug tracker plays in a FOSS project, 2) Describe the different types of issues stored in a bug tracker and their priorities, and 3)Identify and track the status of a particular bug in a project. |
| Materials/Environment | Access to Internet/Web and web browser. |
| Additional Information | ? |
| Rights | Licensed CC BY-SA |
| Turn In | Wiki posting describing the results of your exploration below. |
Background:
Bug tracking systems are a form of change management and organization used by FOSS projects. Bug trackers do far more than simply keep track of bugs. They also are used to hold new feature requests, patches, and some tasks. Bug trackers are also called request trackers, issue trackers, request trackers and ticket systems. Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.
Directions:
We will begin by looking at a typical Bugzilla instance for a project. We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team.
Part 1 - Bug Reports
- Open a browser and go to the GNOME Accessibility Bugs
- Define what each of the column names below indicate. Include the range of possible values for b-g:
- ID
- Sev
- Pri
- OS
- Product
- Status
- Resolution
- Summary
- Describe how you discovered the definitions and How did you find the information from above?
- Identify the order in which the bugs are initially displayed?
- What is the meaning of the blue shading of some bug reports?
- What is the meaning of the colors used when describing a bug (red, gray, black)?
- Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).
- Identify when the bug was submitted.
- Identify if there has been recent discussion about the bug?
- Is the bug current?
- Is the bug assigned? To whom?
- Describe what you would need to do to fix the bug.
- Repeat the previous step with a different kind of bug.
Part 2 - Collective Reports
- Click on the “Reports” link on the top of the page.
- How many bug reports were opened in the last week? How many were closed?
- What was the general trend last week? Were more bugs opened than closed or vice versa?
- Who were the top three bug closers? Why is this important to know?
- Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists?
- Who are the top three contributors of patches?
- Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers?
- Click on the “Generic Reports” link.
- Plot the Severity of each Version of the Accessibility features of Empathy.
- What other reports can you generate?
