7 ms·

The good thing about Bugzilla was that it was clearly a bug tracking system (and it was excellent at that), whereas Jira is only a passable bug tracking system

The good thing about Bugzilla was that it was clearly a bug tracking system (and it was excellent at that), whereas Jira is only a passable bug tracking system pretending to be a project management tool.

hmottestad 8y ago
Can you be more specific? What is missing I've used Jira for quite a few years at work, and the number one issue with Jira that I have found (and also my team) is that bugs that don't get fixed tend to get lost in the mass of everything registered in Jira. Jira does try to both be a place to register bugs (and features and other tasks) while also trying to be a place where you organise how the work should be done (eg. with sprints). I guess Bugzilla doesn't do that?
- achamayou 8y ago
  A good bug entry is (completely) unlike a project planning entry. It comes with detailed environment and repro instructions, artefacts such as logs and screenshots. It’s an investigation, not an item in a wish list, and it’s ideally a place where every dev in the team can chip in and offer additional data or suggestions. If it isn’t used to track progress or productivity, it contains exactly the right number of entries (since there is no incentive to the contrary). The criteria for closing a ticket are very clear, there is no risk to offend someone by closing their half implemented and ultimately insufficiently detailed entry for example. Bugs are either open or fixed! The tool does not figure out who should be fixing which bug, that’s the job of the team lead. When an issue falls on the fence between a feature request and a bug, whoever is allowed to make the call needs to decide and either keep it as a bug, or mark it as wontfix (either out of scope, or to be looked into as a feature). A well maintained bug tracker is valuable to users, because it comes with a good search implementation (Jira’s search is abysmal for error messages!), and then can work if and when the problem they hit has been fixed. Cluttering that with project management does not help!
alkonaut 8y ago
But is it really that useful to track bugs separate from other work? I find that most often it's even hard to agree what IS a bug and what isn't. There is just "work".
- achamayou 8y ago
  A bug is a difference between the intended behaviour of the code and what it actually does! If you regularly can’t decide what tickets are, then you must be working on something that is especially under-defined and under-documented. I would suggest addressing that, and that Jira is not going to help you there.
  - alkonaut 8y ago
    I think the reality is that software is very rarely specified enough that you can go to a central specification and point at it and say "look here in the spec it says it should do X" Something unforseen is occurring that the spec never talked about and that's reality. (trivial example: if you design without full unicode support you don't explicily SAY in a specification that you aren't supporting some characters, nor would you say you DON'T support such characters). And then a customer comes and says his name shows up as gibberish and you have no tests and no spec mentioning whether this is expected or not. It's simply a case that no one had thought of in neither specification nor implementation. The fact that it wasn't specified makes it easy to say "since we didn't expicitly mention it, it must be a bug". It's in my experience usually futile to point fingers towards whether something is a bug or a new feature in this case. The customer obviously doesn't care, to him it's just a bug even if it's a lack of a feature (because the customer doesn't have the specification even if one exists). So to the end user it's very much a bug even if to the development team that may have written a spec that says "it shall be iso8859 and garble any utf-8" it is a completely new feature! And even in the latter case where even the buggy behavior was well-specified, you'd be having a bug report describing the garbled text as a bug. The best you can hope for in a dual bug/feature system is to close the bug report as *wontfix - by design - see feature 123 in the feature tracker 'add unicode support'". This may be a trivial and perhaps obvious example, in most cases these realizations may take a large portion of the time. Now: a public facing bug-report system feeding into a separate bugs-only-tracker can certainly be useful still, but once those end-user bug reports are converted into work, whether it turns into a workitem in a separate system marked "bug" or one that is marked "feature" isn't really that important. Work has to be prioritized in the same queue anyway. The ROI for fixing a bug, specified or not, has to be weighed against the ROI of adding a feature.
PretzelFisch 8y ago
What made it a good bug tracker? I still use it and find may design choices like not being able to edit a bug or comment frustrating. Also the lack of some basic formatting in the bug descriptions.

hmottestad 8y ago

Can you be more specific? What is missing I've used Jira for quite a few years at work, and the number one issue with Jira that I have found (and also my team) is that bugs that don't get fixed tend to get lost in the mass of everything registered in Jira. Jira does try to both be a place to register bugs (and features and other tasks) while also trying to be a place where you organise how the work should be done (eg. with sprints). I guess Bugzilla doesn't do that?

achamayou 8y ago
A good bug entry is (completely) unlike a project planning entry. It comes with detailed environment and repro instructions, artefacts such as logs and screenshots. It’s an investigation, not an item in a wish list, and it’s ideally a place where every dev in the team can chip in and offer additional data or suggestions. If it isn’t used to track progress or productivity, it contains exactly the right number of entries (since there is no incentive to the contrary). The criteria for closing a ticket are very clear, there is no risk to offend someone by closing their half implemented and ultimately insufficiently detailed entry for example. Bugs are either open or fixed! The tool does not figure out who should be fixing which bug, that’s the job of the team lead. When an issue falls on the fence between a feature request and a bug, whoever is allowed to make the call needs to decide and either keep it as a bug, or mark it as wontfix (either out of scope, or to be looked into as a feature). A well maintained bug tracker is valuable to users, because it comes with a good search implementation (Jira’s search is abysmal for error messages!), and then can work if and when the problem they hit has been fixed. Cluttering that with project management does not help!

alkonaut 8y ago

But is it really that useful to track bugs separate from other work? I find that most often it's even hard to agree what IS a bug and what isn't. There is just "work".

achamayou 8y ago
A bug is a difference between the intended behaviour of the code and what it actually does! If you regularly can’t decide what tickets are, then you must be working on something that is especially under-defined and under-documented. I would suggest addressing that, and that Jira is not going to help you there.
- alkonaut 8y ago
  I think the reality is that software is very rarely specified enough that you can go to a central specification and point at it and say "look here in the spec it says it should do X" Something unforseen is occurring that the spec never talked about and that's reality. (trivial example: if you design without full unicode support you don't explicily SAY in a specification that you aren't supporting some characters, nor would you say you DON'T support such characters). And then a customer comes and says his name shows up as gibberish and you have no tests and no spec mentioning whether this is expected or not. It's simply a case that no one had thought of in neither specification nor implementation. The fact that it wasn't specified makes it easy to say "since we didn't expicitly mention it, it must be a bug". It's in my experience usually futile to point fingers towards whether something is a bug or a new feature in this case. The customer obviously doesn't care, to him it's just a bug even if it's a lack of a feature (because the customer doesn't have the specification even if one exists). So to the end user it's very much a bug even if to the development team that may have written a spec that says "it shall be iso8859 and garble any utf-8" it is a completely new feature! And even in the latter case where even the buggy behavior was well-specified, you'd be having a bug report describing the garbled text as a bug. The best you can hope for in a dual bug/feature system is to close the bug report as *wontfix - by design - see feature 123 in the feature tracker 'add unicode support'". This may be a trivial and perhaps obvious example, in most cases these realizations may take a large portion of the time. Now: a public facing bug-report system feeding into a separate bugs-only-tracker can certainly be useful still, but once those end-user bug reports are converted into work, whether it turns into a workitem in a separate system marked "bug" or one that is marked "feature" isn't really that important. Work has to be prioritized in the same queue anyway. The ROI for fixing a bug, specified or not, has to be weighed against the ROI of adding a feature.

PretzelFisch 8y ago

What made it a good bug tracker? I still use it and find may design choices like not being able to edit a bug or comment frustrating. Also the lack of some basic formatting in the bug descriptions.