Continuing the discussion from Community Hardware:
Let’s allow this thread to be a loose discussion, let’s just dump thoughts as we have them. At this point I don’t have a checklist of why JIRA over Bugzilla (but actually we really should). So I can add what JIRA does better over bugzilla as I remember/encounter it.
I do want to note that I don’t believe JIRA does anything that Bugzilla couldn’t easily do if Mozilla were still investing in the tool. Many teams have ended up using Github and Mozilla uses ServiceNow for requests, so that goes to show that we’re not the only team finding Bugzilla lacking these days.
###Github integration###
Speaking of github, here’s a good one. In JIRA you can connect the two. When you make a commit, you simply reference the related JIRA issue. JIRA then imports info from that commit, into that issue.
###Description vs Comment #0###
This one is the killer for me. If JIRA had no other features better than Bugzilla this would make it superior. There is a description area, which is sort of like a wiki area, then there are comments. Many bugs become useless because important information is buried in the comments. Steps to reproduce can be in comment #9 and a workaround can be in comment #20. In JIRA you can put all relevant information on the state of the issue at the top, in the description. No one needs to read the comments ever, though they can be useful for asking each other questions and figuring out why something is in the description.
###Search and filter UX###
This one I think bugzilla technically has the same functionality, but it’s much easier to use in JIRA because of the UX. The search is easier to use, and to edit. It’s also easier to use the saved search option, navigate through issues, and even edit them from the search results.
You can also view an issue while keeping the search results in a side-bar so you can navigate through the list while triaging issues. I don’t always use this view, but I think many people use it as their default view, and it’s been handy.
###Filter subscriptions###
I don’t believe Bugzilla currently does this (oh with the exception of needsinfo). In JIRA you can subscribe to a filter (a filter is a saved search). You can get emailed the list of issues (what JIRA calls bugs) at any interval you like. Daily, weekly, you can even set a super custom time like x minutes if you really wanted to. So if there are critical issues assigned to you, you can get an email reminder of those every day. You could get a weekly summary of all the open issues in a component if you like. You can also set up these subscriptions for everyone in a team and individuals can set up notifications at different intervals for the same filter.
###Epics###
OMG I love epics. I’m not an agile developer, I came across epics and stories from using JIRA, where the names made no sense but the functionality did. Epics are similar to what the participation team is calling “heartbeats” and we use the dependency tree in bugzilla for this. So larger task you want to accomplish “Get the Mozilla community using Discourse” is the Epic, and then there are issues in the epic, so all the different tasks that have to be done to get that going. This is a bit different from tasks and sub-tasks. A task is a smaller action, like “configure Discourse” and sub-tasks might keep track of the different things that need to be configured.
###Linked issue UX###
The UX for this is great. Unlike Bugzilla’s dependencies, when another issue is linked to an issue, you actually see information about that issue. If you are looking at an epic, all the other issues in the epic are listed complete with the summary and status. The same for linked issues, ie blocks, depends on, related. I guess it doesn’t sound like much, but from a project management perspective, having this information in context is super helpful.
…
Ok, so I thought of more to start than I thought I would 