Bug Gardening
(→Comments:) |
(→Directions:) |
||
| Line 37: | Line 37: | ||
Identifying the "suspect" bugs will be easier if you have information from the project about their bug lifecycle or which bugs they would prefer your students focus on. However, even in the absence of that information, there are some other clues that can be used to identify bugs that may no longer exist. | Identifying the "suspect" bugs will be easier if you have information from the project about their bug lifecycle or which bugs they would prefer your students focus on. However, even in the absence of that information, there are some other clues that can be used to identify bugs that may no longer exist. | ||
| − | + | -- Look at 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. | |
| − | 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. | + | |
Once the student teams have identified a bug to work on, they should try to verify the bug status. | Once the student teams have identified a bug to work on, they should try to verify the bug status. | ||
Revision as of 20:40, 17 June 2015
| Title | Bug Grooming / Bug Triage / |
| 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 grooming (/bug triage) techniques, *and* helps the community by doing some of that work. |
| 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 grooming" |
Background:
Bug Gardening (or Grooming or Triage) is the process by which projects:
- confirm new bugs that have been submitted
- gather more information about the bug when necessary
- prioritize confirmed bugs
- review bugs to ensure that they are being worked on
- retire old bugs
This activity, however, is focused on retiring bugs that are no longer relevant (#5), primarily because that is more clear-cut than full-fledged bug triage.
If the project you're working with has a guide for how to triage bugs, the students should read that first. Here are three examples of Bug Triage Guides:
- Gluster Bug Triage Guidelines and their accompanying Lifecycle of a Bug
- Bug Management - How to Triage (MediaWiki)
- Gnome Bug Triage Guide
The student should be familiar with how to use the bug tracker (see Bug Tracker Activity) for the project.
Directions:
Though all bugs need to be triaged (see examples of Bug Triage Guides), this activity is focused on culling bugs that are no longer relevant, primarily because that is more clear-cut than full-fledged bug triage.
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, and
- test the bug to see if it still exists.
Identifying the "suspect" bugs will be easier if you have information from the project about their bug lifecycle or which bugs they would prefer your students focus on. However, even in the absence of that information, there are some other clues that can be used to identify bugs that may no longer exist.
-- Look at 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.
Once the student teams have identified a bug to work on, they should try to verify the bug status.
At that point,
- If the bug is no longer relevant, your students can take one of several courses of action, depending on how well-established your/their relationship with the project is:
- If they have established a good working relationship with a project and have permissions to do so, they can close the bug (this is something a more advanced student might do)
- They can add a comment to the bug with their notes with the suggestion to close. This is more appropriate for students with less project experience.
- If the student can not tell if a bug is still relevant -- that's ok. At that point they can:
- Move on and try another bug, or
- Ask for more information from the bug reporter or the person assigned to the bug. This can be a valuable because it exposes students to more of the project ecosystem.
Deliverables:
At the end of the exercise, the student teams should have a list of bugs that they investigated and the outcomes. In the ideal case, they will have been able to close a bug or two, but even if they haven't you should still receive a report out. I suggest the following as a sample format (I've filled two lines as examples):
| Bug Number | Short Description | URL for Bug | Analysis | Actions Taken |
| Bug 302338 | Machine Explodes on Disk Insertion | http://example.com/fakebug.enter_bug.cgi?product=fake&bug=302338 | Bug submitted against version 2 of product, which was EOL'd in 2003 | Left comment suggesting that bug be closed |
| Bug 42984 | Funny Noises | http://example.com/fakebug.enter_bug.cgi?product=fake&bug=42984 | Bug submitted in 2010, patched in release 2 (2011) | Closed bug. |
Assessment:
How will the activity be graded?
How will learning will be measured?
Include sample assessment questions/rubrics.
Comments:
If you're working with a specific open source project:
- 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.
- let the project know that your students will be doing this -- an influx of activity on a bug tracker can be overwhelming if unexpected
Other projects may have similar set-ups that are worth asking about.
Variation If you're working with a specific open source project and you have a block of time at least 1.5 hours long, you may want to run a bug sprint. You may be able to find a time when the regular "bug wrangler(s)" from the project can join you (via IRC or Google Hangout) and offer your students "live" assistance with triaging bugs.
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. If your students will be making changes, they will also need to join the IRC channel or mailing list where bugs are discussed (the bug triage info should mention this), and if they are going to be making changes, they will need a login to the bug tracker. |
| 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
