Intro to Bug Trackers (Activity)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(Undo revision 10660 by Sfashoto (talk))
(Update link to GNOME issues)
 
(15 intermediate revisions by 5 users not shown)
Line 3: Line 3:
 
{{Learning Activity Overview
 
{{Learning Activity Overview
 
|title=
 
|title=
−
Intro to Bug Trackers
+
Intro to Issue Trackers
 
|overview=  
 
|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.  
+
Learners will gain an understanding of the features of issue trackers and how they are used to identify work items to be completed in a FOSS project.  
 
|prerequisites=
 
|prerequisites=
 
None.
 
None.
 
|objectives=
 
|objectives=
−
# Describe the role that a bug tracker plays in a FOSS project.
+
# Describe the role that a issue tracker plays in a FOSS project.
−
# Describe the different types of issues stored in a bug tracker and their priorities.
+
# Describe the different types of issues stored in a issue tracker and their priorities.
−
# Identify and track the status of a particular bug in a project.  
+
# Identify and track the status of a particular issue in a project.  
 
|process skills=
 
|process skills=
 
}}
 
}}
Line 18: Line 18:
 
=== Background ===
 
=== Background ===
  
−
Bug tracking systems are a tool for change management and organization used by FOSS projects.  
+
Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue trackers and their use in 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, 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]
Line 29: Line 25:
 
=== Directions ===
 
=== Directions ===
  
−
We will begin by looking at a typical Bugzilla instance for a project.
+
# Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/groups/GNOME/-/issues.
−
We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team.
+
# GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issue has an issue number prefixed by its project name.)
−
 
+
# What other information is available about each issue in this view?
−
== Part 1 - Bug Reports ==
+
# Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.
−
# Open a browser and go to the [https://bugzilla.gnome.org/buglist.cgi?type0-7-0=notequals;field0-3-0=product;keywords=accessibility;type0-1-0=notequals;type0-5-0=notequals;keywords_type=allwords;value0-5-0=accerciser;value0-4-0=at-poke;field0-1-0=product;field0-0-0=product;type0-4-0=notequals;field0-6-0=product;value0-3-0=gnome-mag;field0-7-0=product;query_format=advanced;value0-2-0=Dasher;value0-6-0=gnome-speech;value0-1-0=Gok;type0-3-0=notequals;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;field0-2-0=product;field0-5-0=product;field0-4-0=product;type0-6-0=notequals;type0-0-0=notequals;value0-0-0=Orca;type0-2-0=notequals GNOME Accessibility Bugs]
+
# Browse through a couple of issues. What additional information is provided on individual issues?
−
# 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.
+
# Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?
−
## ID
+
# Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?
−
## Sev
+
# Milestones do three things: 1. they aggregate a set of issues and 2. they associate a deadline with those issues, and 3. they provide a progress bar to visualize the status of a milestone. Milestones can be used to collect issues for an upcoming release, organize a time-boxed development effort (as in a Scrum Sprint), or they can be used to collect issues that compose a larger feature to be implemented. Click on "milestones" in the left menu. Browse through two or three of them. How does GNOME appear to be using milestones?
−
## Pri
+
# Click on "Merge Requests" in the left menu. These look a lot like issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?
−
## OS
+
−
## Product
+
−
## Status
+
−
## Resolution
+
−
## Summary
+
−
# 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).
+
−
# Identify the order in which the bugs are initially displayed.
+
−
# 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)
+
−
# 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.
+
−
# Click on the "Summary of Bug Activity for the last week".
+
−
# How many bug reports were opened in the last week? How many were closed? ''(254 reports opened and 220 reports closed''
+
−
# What was the general trend last week? Were more bugs opened than closed or vice versa? ''There were more bugs opened than closed''
+
−
# Who were the top three bug closers? Why is this important to know? ''Nick Wellnhofer: 37, Matthias Clasen: 14 and Michael Schumacher: 9. It is important to know who are the best contributors to fixing and closing bugs in the system to ask them for help when needed''
+
−
# 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? ''Piotr Drąg: 9, Stephen: 8 and Mohammed Sadiq: 7. They are not the same as the top three bug closes. Bug reporters are the ones who report finding bugs when tey try the system and they are not necessarily the same people who can fix those bugs and close them''
+
−
# Who are the top three contributors of patches? ''Debarshi Ray: 24, Florian Müllner: 22 and Georges Basile Stavracas Neto: 9''
+
−
# 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? ''Florian Müllner, Debarshi Ray and Sebastian Dröge (slomo). Two of the top contributers of patches are among the top patch reviewers but non of the top three contributors of patches or reviewers of patches were involved in closing the bugs''
+
−
# Click on the “Generate Graphical Reports” link.
+
−
# Plot a line graph of the severity of bugs by component for Orca:
+
−
## Select "Severity" for the vertical axis
+
−
## Select "Component" for the horizontal axis
+
−
## Select "Bar Graph" for type of graph
+
−
## Leave the "Multiple Images" as <none>
+
−
## Scroll down and select Orca from the Product menu.
+
−
## Click "Generate Report".  
+
−
# What class were the majority of the bugs for braille? ''Normal and General components''
+
−
# What other reports can you generate? ''Comments, URL, Whiteboard, Keywords, Bug Numbers, Version, Target Milestone, Severity, Priority, Hardware, OS''
+
−
 
+
−
 
+
−
===Deliverables ===
+
−
 
+
−
POSSE: On your user wiki page, a section describing the results of your exploration below.
+
  
 
= Notes for Instructors =
 
= Notes for Instructors =
Line 128: Line 83:
 
|author=
 
|author=
 
Heidi Ellis
 
Heidi Ellis
 +
Stoney Jackson
 
|source=
 
|source=
 
|license=
 
|license=

Latest revision as of 19:47, 22 May 2019


Title

Intro to Issue Trackers

Overview

Learners will gain an understanding of the features of issue 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 issue tracker plays in a FOSS project.
  2. Describe the different types of issues stored in a issue tracker and their priorities.
  3. Identify and track the status of a particular issue in a project.
Process Skills
Practiced


Background

Issue tracking systems are a tool for change management and organization used by FOSS projects. Issue trackers are used to hold bug reports, new feature requests, patches, and some tasks. Issue trackers are also called request trackers, bug trackers, and ticket systems. Please read the two readings below for a more complete treatment of issue trackers and their use in FOSS projects.

Directions

  1. Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/groups/GNOME/-/issues.
  2. GItLab allows groups with multiple projects to view all their issues in an aggregated view. This is what you are viewing now. List some of the projects that these issues belong to (hint - each issue has an issue number prefixed by its project name.)
  3. What other information is available about each issue in this view?
  4. Issues can be assigned labels which are also visible from this view. These are the colorful labeled ovals. List a few of the labels that you see. Feel free to browse through pages.
  5. Browse through a couple of issues. What additional information is provided on individual issues?
  6. Click on "labels" in the left menu. Notice that labels are grouped by number and color. For example, gold (olive?) labels start with "1." and represent the type of the issue, which can be used to quickly search for issues of a certain type and to know what type an issue is at a glance. What other groups are there, and how do you think they are used?
  7. Click on "board" in the left menu. Boards are used to organize issues. This board provides a high-level roadmap of the projects in GNOME. How are cards associated with columns?
  8. Milestones do three things: 1. they aggregate a set of issues and 2. they associate a deadline with those issues, and 3. they provide a progress bar to visualize the status of a milestone. Milestones can be used to collect issues for an upcoming release, organize a time-boxed development effort (as in a Scrum Sprint), or they can be used to collect issues that compose a larger feature to be implemented. Click on "milestones" in the left menu. Browse through two or three of them. How does GNOME appear to be using milestones?
  9. Click on "Merge Requests" in the left menu. These look a lot like issues. Browse through a few. What do they have that issues do not? Often merge-requests contain links back to the issue that they are related to. What is the syntax for linking a Merge-Request to an issue?

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 Stoney Jackson

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=13468"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox