I worked on the design of Launchpad’s bug tracker (along with other parts of Launchpad) from 2005 to 2007. We got some things wrong, but I think at least we improved on Bugzilla. ;-)

The purpose of a bug tracker is to improve software. It does this by helping developers make the best use of their time, giving answers to the question, “What should I do next?”.

It is easy to confuse this purpose with other possible purposes. For example, it is not the purpose of a bug tracker to act as a tech support forum. A bug report used as a support forum rapidly becomes harder and harder to use as a forge for actually fixing the bug. So, it may be interesting to put reporters in touch with other people suffering the same problem, but when designing a feature like that you would need to be careful not to encourage chit-chat in the bug report itself.

As another example, it is not the purpose of a bug tracker to make it easy to comment on bugs. Bugzilla got this wrong, with large comment fields and comment numbering and reply quoting and so on, which made it easier to chat in a bug report and therefore harder to pay attention to bug notifications or to understand what a bug report is actually about.

Most importantly, it is not necessarily the purpose of a bug tracker to make it easy to report bugs. As the number of open bug reports increases linearly, the time for triagers and engineers to deal with those reports also increases nearly linearly, but the probability that any of those bugs will be the most important thing for a developer to work on next *decreases* exponentially (because new reports are more often duplicates, or tiny edge cases, than old ones are). So, sometimes more bug reports are actually a bad thing.¹

For example, right now Ubuntu has 96180 open bug reports, of which 56241 — more than half — are “New”, i.e. Unconfirmed.So what would help Ubuntu improve most are things like better duplicate detection, more efficient triage, and possibly even *fewer* bug reports to begin with.² None of that would be helped by a GUI application for bug reporting.

That isn’t true for every project, though. A project may have few users, but an active maintainer, who is happy to give careful attention to every bug report. In that case, bug reporting should be easy, and some of the other features you describe would make sense.

One awkward thing about Launchpad’s bug tracker is that it doesn’t cater for this variety of projects. It is exactly as easy to report a bug on a project that is overflowing with bug reports, than on a project that really would like more of them .

¹ In a public open-source project, this isn’t the whole story. For example, a new contributor may start out by browsing the bug list, and pick a low-importance bug first because it’s easy to fix.
² For example,anyone used to be able to report a bug on Ubuntu without specifying the package first. Nowadays, you can do that only if you’re a member of a particular team, or if you know the secret URL. This is a rough way of simultaneously making bug-reporting a bit harder, and making triaging, on average, a bit faster.