It would be nice if there was a way to specify a Due Date for bugs. This would be a field where you would specify the date a bug needs to be fixed by. I realize this is similar to the Milestone field, but Milestones are sort of coarce values, it doesn't give you the granularity an actual date field would bring. You would of course then be able to sort on this field in the bug list and you would actually see a bug fixing schedule. You may even go so far as to add an ETA date field, but then that is to much duplication with the milestone field anyway. Having a due date field also opens up the opportunity for some great reports. By comparing the due date with the date a bug was marked resolved, you can create reports such as how many bugs were fixed early, how many were fixed on time, or how many were late. Since Mozilla.org doesn't really set any firm deadlines or anything, I can see why this field wasn't called for before, but now that Bugzilla is used in more and more places, I expect there is a wide-spread need for a field of this nature.
Another feature that could go along with this, would be with the whineatnews feature. There could be the ability to whine when a bug is due within a day or 2 or whatever and it is no currently resolved.
This would be a great feature. A current client is prepending the Summary with ISO dates as a workaround. The date feature would allow Bugzilla to function as a project planning tool. Reporting could be built around this feature that would allow Gannt charting, as well. But I suppose that's for another bug.
I agree. I digress, but "estimated work hrs", "cummulative work hrs", and "percent completed" fields also would help to see how far off the "Due Date" might be missed. "estimated work hrs" .vs. "cummulative work hrs" will help orgs to determine the historic reliabilty of their estimates. "perecent completed" * "estimated work hrs" can be compared with the "due date" do determine if due dates are unreasonable or high-risk for meeting schedule. There are scores of other metrics that can be determined from the combination of these 4. The problem with metrics like these are they they could be used by unscrupulous project mgrs to prove someone's "ineffectiveness". Anyway, I can certainly justify them in most orgs I've worked in. In general, I wish bugzilla was less of an "open-source software bug" tracking tool and more general process tracking tool. Most of the commerical software industry would benefit from more open process tracking tool. A lot of commercial process tracking tools are much more flexible than bugzilla. The problem with bugzilla is that you cannot add new fields easily: different processes require different metrics. Unfortunatly, not everyone develops software with an open-source process. Someone has alerted me that there is a bug that is related to the general problem. See Bug#91037.
See bug 24789, too.
Is this a dupe of bug 103636?
Yep, thanks *** This bug has been marked as a duplicate of 103636 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.