Evaluating Issue Tracking Software
Goals for In-Class Work
- Hands-on experience with issue tracking software
- Critical evaluation of software tools
Objective: Evaluating Issue Tracking Software
We have been talking a lot about software tools and their tradeoffs. Let's make this concrete.
Put your evaluations in the shared notes.
You are to evaluate the below tools on the following criteria:
- How do you perform each of the following tasks in the tool?
How easy is it to perform each of the tasks?
- Browsing bug reports
- Searching for/filtering bug reports (how does the tool enable search?)
- Viewing the details of a bug report (how does the bug report map back to the theory we talked about in class?)
- Submitting a bug report (if you can find that--check documentation too)
- What other cool/useful features does the software have?
- Overall, what do you like and not like about each user interface?
There is likely other criteria you would use to evaluate the tools (how much support each tool provides; what other software you're using for your project), but we'll just focus on the above criteria (with a bit of a nod toward open-source vs commercial software, see below).
After creating a summary of your evaluation based on the criteria above (can be in paragraph or bulleted form; it just needs to be clear), compare and contrast the tools.
Finally, summarize which tool would you recommend to your team to use for bug tracking under various circumstances.
The Tools to Evaluate, Alphabetically
- Open-source, freely available Bugzilla, specifically the instance of Bugzilla for Mozilla and look for the bugs for Firefox.
- (Pretending Commercially Available) Facebook's Bug Reports
- GitHub issues: GitHub, for one particular project Runestone
- Commercially Available (free plans available) JIRA. As an example, check out the instance of Minecraft's JIRA and, specifically, for its Java edition
- Open-source, freely available Trac, specifically the instance of FileZilla's Trac