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