Welcome, Unregistered Visitor
Welcome, Unregistered Visitor
1 registered user
in last 24 hours
OpenACS Bug Tracker
Original Text by Lars Pind
Development will focus on getting a working version up and running within about a week and a half, and then have a product that we can incrementally improve on as we have the time and need.
Scenario 1: Tom finds a bugTom is using the software and it's not behaving like he thought it would. He visits the bug-tracker and is greeted with a list of known bugs in his version of the software (he's previously told the bug-tracker what version he's using, and this version is being shown clearly on each page, along with what version is the latest released version, and which is the current development version). (Had he had any bugs assigned to him, he would've been greeted with the list of bugs assigned to him instead.) He drills down the list of known bugs by clicking on the name of the component that's causing him trouble. Nope, still not there. He clicks the "new bug" link and enters the info on the new bug: What he did, what he expected to happen, what happened instead. His version and the component has already been filled in. He can upload a file right here, and he can also upload more files later. There's a checkbox letting Tom choose whether to get email alerts on all activity on this bug.
Scenario 2: Jack maintains a packageJack gets an email alert saying there's a new bug. He checks out the bug description in the email and decides that this is worth looking at. He visits the page, sets the priority to High, assigns it to one of his trusted slaves, and goes back to the beach.
Later, he visits bug-tracker, and is greeted with a list of bugs he's assigned to. Phew. Then he checks the activity report for the past week for the bugs he's the maintainer of, whether assigned to them or not, to see if bugs are getting closed or if they're piling up. He decides it's time to go squash some bugs. He goes back to the "my bugs" list, which is already sorted by priority, then user rating (user rating is going to be in a later version), then date of entry (descending). Clicks the first, fixes, then hits "Next", fixes, then hits "Next", fixes ...
Differences from SDM
Page FlowchartThis is the pages there are and how they're related:
Workflow (A Bug's Life)We have separate STATUS and RESOLUTION codes. Possible STATUS codes are:
We will not, in this version, bother with triage and QA steps. The submitter of a bug is also the person to close that bug. The maintainer of the project or component is the first assignee, and takes it from there. There is no unassigned state.
BugZilla has many more status codes. For example they have a confirmation step, in which it's checked that the bug is "a true bug". They have a status to say that the bug has been assigned. They have a special "reopened" step. And they have a "Verified" step, and only allow the bug in "Closed" when the release in which the bug has been fixed has actually shipped. We won't go there in this version of the bug-tracker.
The RESOLUTION code to one of the following:
Other Bug Classifications
Type of bug (hard-coded)
Severity (can be modified)
Priority (can be modified)
Main NavigationThere's a navigation bar which is present on all pages in the bug-tracker, and contains links to:
Index page: Ticket list(Mock-up)
The index page of the package is the ticket list page. The ticket list page displays a list of tickets in a combination of Google style and webmail style, i.e., each bug is displayed like this:
It's Google, because each bug takes up several lines, and information is shown "organically" for each bug. It's webmail, because each bug has a checkbox next to it, which can be used for bulk operations.
Tickets are shown 20/50/100/200 per page, and you can page browse through them like in a typical web mail interface.
Predefined filters include: "My bugs", "Open bugs in the current version", "All bugs in my version", "Open bugs that I'm the maintainer of", etc.
You can enter what version you're using, so that it defaults to that version when you're entering bugs and searching for known bugs. The version you've selected will be displayed very clearly on each page.
The ticket list page can be scoped to one component. The contents will look just the same and you can use the same filters, only everything will be scoped to the component you selected. When you submit a bug from inside a component level, the component name is already filled out and cannot be changed.
Enter New Ticket
View TicketWhen viewing a ticket, you have the usual webmail operators: First/Last/Next/Prev.