Intro to Bug Trackers (Activity)

(Difference between revisions)
Jump to: navigation, search
(→Part 1 - Bug Reports)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
−
{| border="1"
 
−
|-
 
−
|'''Title''' ||Bug Trackers
 
−
|-
 
−
|'''Overview''' || 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.
 
−
|-
 
−
|'''Prerequisite Knowledge''' || None
 
−
|-
 
−
|'''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.
 
−
|}
 
  
 +
{{Learning Activity Overview
 +
|title=
 +
Intro to Bug Trackers
 +
|overview=
 +
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.
 +
|prerequisites=
 +
None.
 +
|objectives=
 +
# Describe the role that a bug tracker plays in a FOSS project.
 +
# Describe the different types of issues stored in a bug tracker and their priorities.
 +
# Identify and track the status of a particular bug in a project.
 +
|process skills=
 +
}}
  
−
=== 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.
+
=== Background ===
 +
 
 +
Bug tracking systems are a tool for 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.
  
 
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]
 
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]
−
* [http://en.wikipedia.org/wiki/Bug_tracking_system Wikipedia's page on Bug Tracking Systems]
+
* [http://en.wikipedia.org/wiki/Bug_tracking_system Bug Tracking System (Wikipedia)]
 +
 
 +
=== Directions ===
  
−
=== Directions: ===
+
We will begin by looking at a typical Bugzilla instance for a project.  
−
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.  
+
We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team.  
  
 
== Part 1 - Bug Reports ==
 
== Part 1 - Bug Reports ==
Line 45: Line 56:
  
 
== Part 2 - Collective 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.
 
# Click on the "Summary of Bug Activity for the last week".
 
# Click on the "Summary of Bug Activity for the last week".
Line 65: Line 77:
  
  
−
===Deliverables: ===
+
===Deliverables ===
 +
 
 
POSSE: On your user wiki page, a section describing the results of your exploration below.
 
POSSE: On your user wiki page, a section describing the results of your exploration below.
  
 
= Notes for Instructors =
 
= Notes for Instructors =
 +
 
The remaining sections of this document are intended for the instructor.  They are not part of the learning activity that would be given to students.
 
The remaining sections of this document are intended for the instructor.  They are not part of the learning activity that would be given to students.
  
 
===Assessment: ===
 
===Assessment: ===
−
How will the activity be graded?
 
−
 
−
How will learning will be measured?
 
  
−
Include sample assessment questions/rubrics.
+
* How will the activity be graded?
 +
* How will learning will be measured?
 +
* Include sample assessment questions/rubrics.
  
 
{| border="1" class="wikitable"
 
{| border="1" class="wikitable"
Line 100: Line 113:
 
|}
 
|}
  
−
=== Comments: ===
+
=== Comments ===
−
What should the instructor know before using this activity?
+
  
−
What are some likely difficulties that an instructor may encounter using this activity?
+
* What should the instructor know before using this activity?
 +
* What are some likely difficulties that an instructor may encounter using this activity?
  
 +
{{Learning Activity Info
 +
|acm unit=
 +
|acm topic=
 +
|difficulty=
 +
Easy
 +
|time=
 +
60 minutes
 +
|environment=
 +
Access to Internet/Web and web browser.
 +
|author=
 +
Heidi Ellis
 +
|source=
 +
|license=
 +
{{License CC BY SA}}
 +
}}
  
−
=== Additional Information: ===
+
=== Suggestions for Open Source Community: ===
−
{| border="1"
+
−
|-
+
−
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]
+
−
|-
+
−
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf
+
−
|-
+
−
|'''Level of Difficulty''' || Easy
+
−
|-
+
−
|'''Estimated Time to Completion''' ||  60 Minutes
+
−
|-
+
−
|'''Materials/Environment''' || Access to Internet/Web and web browser.
+
−
|-
+
−
|'''Author''' || Heidi Ellis
+
−
|-
+
−
|'''Source''' || None.
+
−
|}
+
  
−
=== Suggestions for Open Source Community: ===
 
 
Suggestions for an open source community member who is working in conjunction with the instructor.
 
Suggestions for an open source community member who is working in conjunction with the instructor.
  
  
−
{{License CC BY SA}}
 
 
[[Category:Learning Activity]]
 
[[Category:Learning Activity]]
 
[[Category:Communication and Tools]]
 
[[Category:Communication and Tools]]
 
[[Category:CS Principles]]
 
[[Category:CS Principles]]
 
[[Category:CS2]]
 
[[Category:CS2]]

Revision as of 13:56, 6 February 2017


Title

Intro to Bug Trackers

Overview

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.

Prerequisites

None.

Learning
Objectives 		After successfully completing this activity, the learner should be able 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.
  3. Identify and track the status of a particular bug in a project.
Process Skills
Practiced


Background

Bug tracking systems are a tool for 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

  1. Open a browser and go to the GNOME Accessibility Bugs
  2. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.
    1. ID
    2. Sev
    3. Pri
    4. OS
    5. Product
    6. Status
    7. Resolution
    8. Summary
  3. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link).
  4. Identify the order in which the bugs are initially displayed.
  5. What is the meaning of the shading of some bug reports?
  6. What is the meaning of the colors used when describing a bug (red, gray, black)? (Hint: click on the Bug ID and examine the fields)
  7. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).
    1. Identify when the bug was submitted.
    2. Identify if there has been recent discussion about the bug?
    3. Is the bug current?
    4. Is the bug assigned? To whom?
    5. Describe what you would need to do to fix the bug.
  8. Repeat the previous step with a different kind of bug.

Part 2 - Collective Reports

  1. Click on the “Reports” link on the top of the page.
  2. Click on the "Summary of Bug Activity for the last week".
  3. How many bug reports were opened in the last week? How many were closed?
  4. What was the general trend last week? Were more bugs opened than closed or vice versa?
  5. Who were the top three bug closers? Why is this important to know?
  6. 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?
  7. Who are the top three contributors of patches?
  8. 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?
  9. Click on the “Generate Graphical Reports” link.
  10. Plot a line graph of the severity of bugs by component for Orca:
    1. Select "Severity" for the vertical axis
    2. Select "Component" for the horizontal axis
    3. Select "Bar Graph" for type of graph
    4. Leave the "Multiple Images" as <none>
    5. Scroll down and select Orca from the Product menu.
    6. Click "Generate Report".
  11. What class were the majority of the bugs for braille?
  12. What other reports can you generate?


Deliverables

POSSE: On your user wiki page, a section describing the results of your exploration below.

Notes for Instructors

The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.

Assessment:

  • How will the activity be graded?
  • How will learning will be measured?
  • Include sample assessment questions/rubrics.
Criteria Level 1 (fail) Level 2 (pass) Level 3 (good) Level 4 (exceptional)
The purpose of the project
Why the project is open source

Comments

  • What should the instructor know before using this activity?
  • What are some likely difficulties that an instructor may encounter using this activity?
ACM BoK
Area & Unit(s)
ACM BoK
Topic(s)
Difficulty

Easy

Estimated Time
to Complete

60 minutes

Environment /
Materials

Access to Internet/Web and web browser.

Author(s)

Heidi Ellis

Source
License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

CC license.png


Suggestions for Open Source Community:

Suggestions for an open source community member who is working in conjunction with the instructor.

Retrieved from "http://foss2serve.org/index.php?title=Intro_to_Bug_Trackers_(Activity)&oldid=8707"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox