Bug Gardening
(→Directions:) |
|||
| Line 8: | Line 8: | ||
|'''Prerequisite Knowledge''' || Students should be familiar with how bug trackers work -- see [[http://foss2serve.org/index.php/Bug_Tracker_Activity| Bug Tracker Activity]] | |'''Prerequisite Knowledge''' || Students should be familiar with how bug trackers work -- see [[http://foss2serve.org/index.php/Bug_Tracker_Activity| Bug Tracker Activity]] | ||
|- | |- | ||
| − | |'''Learning Objectives''' || | + | |'''Learning Objectives''' || Student should be able to review a bug to see if it still is relevant *and* student should be able to explain the importance of "bug gardening" |
|} | |} | ||
Revision as of 19:59, 16 June 2015
| Title | Bug Gardening / Bug Triage / Bug Grooming / |
| Overview | Most projects have a backlog of bugs that need to be periodically “gardened.” Sometimes there are even old bugs that may have already been fixed that just haven’t been closed in the system. This module familiarizes students with bug gardening (/bug triage/ bug grooming) techniques, *and* helps the community by doing some of that gardening. |
| Prerequisite Knowledge | Students should be familiar with how bug trackers work -- see [Bug Tracker Activity] |
| Learning Objectives | Student should be able to review a bug to see if it still is relevant *and* student should be able to explain the importance of "bug gardening" |
Background:
If the project you're working with has a guide for how to triage bugs, the students should read that first.
Here are two examples:
- Gluster Bug Triage Guidelines and their accompanying Lifecycle of a Bug
- Bug Management - How to Triage (MediaWiki)
The student should be familiar with how to use the bug tracker (see Bug Tracker Activity)
If you're working with a specific open source project, you may want to ask the project (via IRC or mailing list) if there are a particular set of bugs that your students should focus on. For example, in the Gluster project I noted above, if a bug is tagged POST it means that an initial patch for a bug has been put into the Gerrit code review tool. If there is a very old bug that's marked POST, there's a decent likelihood that the patch has been incorporated into the project and the bug wasn't closed for whatever reason. If your students can verify this and close the bug, that's valuable.
Other projects may have similar situations that are worth asking about.
Directions:
This activity is best performed in groups of two or three students, who can work together to:
- identify a "suspect" bug in the bug tracker,
- test it to see if it still exists, and
- if it doesn't, close the bug.
Identifying the "suspect" bugs will be easiest if you have information from the project about their bug lifecycle or have information directly from the project about which bugs to focus on, but even in the absence of that information, there are some other clues that can be used to identify bugs that might no longer be bugs.
One thing to look at is the version number of the software that the bug was reported against (versus the one that's current now). If the bug is for a version that's several releases out of date, there's a good likelihood that the issue may have been fixed (or may have just become irrelevant) in the meantime.
Another possible hint is the date on the bug: bugs that were reported years ago may have been fixed and are probably worth looking at first.
Deliverables:
What will the student hand in?
Assessment:
How will the activity be graded?
How will learning will be measured?
Include sample assessment questions/rubrics.
Comments:
What should the instructor know before using this activity?
What are some likely difficulties that an instructor may encounter using this activity?
Additional Information:
| Knowledge Area/Knowledge Unit | Software Development Fundamentals//Software Verification and Validation |
| Topic | Defect tracking |
| Level of Difficulty | Medium (requires some understanding of the intended functionality of the software, ability to use bug tracking software, and critical thinking skills) |
| Estimated Time to Completion | How long should it take for the student to complete the activity? |
| Materials/Environment | Student needs access to the project's bug tracker, internet access |
| Author | Gina Likins |
| Source | 14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star |
| License | This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License |
Suggestions for the Open Source Project:
Your community should have specific expectations around [support] that are published [somewhere]. For example, if your code will only work on Fedora versions newer than 19, then specify that.
If there are a set of bugs that it would be more helpful to have someone verify, then marking those in some way would help the instructor.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
