Intro to Bug Trackers (Activity)
From Foss2Serve
(Difference between revisions)
(→Part 1 - Bug Reports) |
Heidi.ellis (Talk | contribs) (Update link to GNOME issues) |
||
| (18 intermediate revisions by 7 users not shown) | |||
| Line 3: | Line 3: | ||
{{Learning Activity Overview | {{Learning Activity Overview | ||
|title= | |title= | ||
| − | Intro to | + | Intro to Issue Trackers |
|overview= | |overview= | ||
| − | Learners will gain an understanding of the features of | + | 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 | + | # Describe the role that a issue tracker plays in a FOSS project. |
| − | # Describe the different types of issues stored in a | + | # Describe the different types of issues stored in a issue tracker and their priorities. |
| − | # Identify and track the status of a particular | + | # Identify and track the status of a particular issue in a project. |
|process skills= | |process skills= | ||
}} | }} | ||
| Line 18: | Line 18: | ||
=== Background === | === 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | Please read the two readings below for a more complete treatment of | + | |
* [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 === | ||
| − | + | # Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/groups/GNOME/-/issues. | |
| − | + | # 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? | |
| − | + | # 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. | |
| − | + | # Browse through a couple of issues. What additional information is provided on individual issues? | |
| − | + | # 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? | |
| − | + | # 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? | |
| − | + | # 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? | |
| − | + | # 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? | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | 1. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | # Click on | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | # | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | # | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
= Notes for Instructors = | = Notes for Instructors = | ||
| Line 142: | 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:
|
| 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
- Open a browser and go to GNOME's issue tracker on GitLab: https://gitlab.gnome.org/groups/GNOME/-/issues.
- 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?
- 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.
- Browse through a couple of issues. What additional information is provided on individual issues?
- 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?
- 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?
- 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?
- 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
|
Suggestions for Open Source Community:
Suggestions for an open source community member who is working in conjunction with the instructor.
