If you are looking at an epic, all the other issues in the epic are listed complete with the summary and status. Unlike Bugzilla’s dependencies, when another issue is linked to an issue, you actually see information about that issue. A task is a smaller action, like “configure Discourse” and sub-tasks might keep track of the different things that need to be configured. This is a bit different from tasks and sub-tasks.
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. Epics are similar to what the participation team is calling “heartbeats” and we use the dependency tree in bugzilla for this. 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. 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. You could get a weekly summary of all the open issues in a component if you like. So if there are critical issues assigned to you, you can get an email reminder of those every day.
Daily, weekly, you can even set a super custom time like x minutes if you really wanted to. You can get emailed the list of issues (what JIRA calls bugs) at any interval you like. In JIRA you can subscribe to a filter (a filter is a saved search). I don’t believe Bugzilla currently does this (oh with the exception of needsinfo). I don’t always use this view, but I think many people use it as their default view, and it’s been handy. 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.
It’s also easier to use the saved search option, navigate through issues, and even edit them from the search results. The search is easier to use, and to edit. This one I think bugzilla technically has the same functionality, but it’s much easier to use in JIRA because of the UX. 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. In JIRA you can put all relevant information on the state of the issue at the top, in the description. Steps to reproduce can be in comment #9 and a workaround can be in comment #20. Many bugs become useless because important information is buried in the comments. There is a description area, which is sort of like a wiki area, then there are comments. If JIRA had no other features better than Bugzilla this would make it superior. JIRA then imports info from that commit, into that issue. When you make a commit, you simply reference the related JIRA issue. 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. 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. So I can add what JIRA does better over bugzilla as I remember/encounter it. At this point I don’t have a checklist of why JIRA over Bugzilla (but actually we really should). Let’s allow this thread to be a loose discussion, let’s just dump thoughts as we have them. I am a daily user of both tools and I am not sure what can Jira do more than Bugzilla ( honestly).
0 kommentar(er)
