Tags with zero bugs are listed in the tag listing portlet

I also think that showing a tag cloud in place of a default list of bugs on +bugs could make the page look more interesting, and be a more useful image of bug activity than a list of bugs the user didn't ask for.

I don't think anyone is really using the tags at the moment. When I've seen them used it's been the occasional bug that seems to have a word association list attached to it..

The list is currently twice as long as the list of bugs which is annoying.

There is also no obvious way to add tags when submitting.

Adding tags when reporting a bug is bug 54359.

At the very least, we shouldn't show bugs that are used zero times. (For example, the bug listing for Malone itself features the unused "intelvideo" and "xorg" tags.)

I think you should remove all tags from https://launchpad.net/distros/ubuntu/+bugs. The problem is that people seem to be able to make tags which have the same names as packages (worth a separate bug report?), and this causes confusion, because:

1. They can find a list of tags on the above page, and not a list of packages, so will often click on the tag rather than searching for the package; and
2. The list of bugs tagged is never as comprehensive as the list of bugs in a particular package; and
3. As a result, they will not be able to find the bug they are looking for.

All in all, it makes it harder to find bugs. A technically competent friend of mine recently sent me a list of reasons why he isn't able to find the bug he filed on Ubuntu (except via google), this was one of them.

With the new grey boxes, this is more problematic in that I can't hide them anymore in a collapsed box. Makes otherwise clean pages fairly annoying, but this might be only me. https://bugs.edge.launchpad.net/ubuntu

Maybe showing the top 10 tags and then a link to expand / search an exhaustive list would be "better."

it breaks "scroll to bottom" (i have a mouse gesture for this, but applies to dragging the scrollbar, too) as it now does not scroll to the bottom of the result set but to the bottom of this questionable list of tags...

I think Kiko has a fix for this.

Landed in RF 6785, enjoy on edge shortly.

Still an issue on r6976.
See: https://bugs.edge.launchpad.net/ubuntu/ and watch it render an extremely huge page vertically.

I have some more info.
It seems that if multiple Invalid/Fix Released bugs share a tag, the tag count will always be 1 for those tags.

I am setting it back to new, as there are still too many bugs listed, and some of the tags don't actually link to bugs. I originally filled a new bug report but it was set as a dup of this one, so I guess I should have just appended to this report..

Well.. I've morphed this bug to cover the fix I actually landed <wink>. With this fix, tag listings for source packages are actually manageable, so it's definitely an improvement. There are a few follow-up issues that need to be addressed:

  - The tag listing for Ubuntu itself is still way too long. The main issue there is that there are many tags listed with one (or a very small number) of bugs associated.
  - One solution to that would be to cap the list to a useful maximum. However, how do you cap? And is it really fair to exclude officially endorsed tags that may have less bugs associated than other randomly-set tags?
  - Another solution is to actually make explicit which tags are official to the project in context, and only display those tags in the portlet. This is the topic of bug 159036. A separate page would render a tag cloud with the full set of tags -- there's no bug reported for that, though.
  - The fact that we link to bug listings that use the default filters mean that tags for which there are no open bugs seem to link to empty listings. This would be less grave if it were not for the fact that the search filters are not visible at all: fixing bug 28697 would make this less confusing.
  - At any rate, we could also choose to link to bug listings that included closed bugs. The con with this is that the tag listing will grow without natural bounding over time. That's bug 137621
  - Being consistent at least in the filter used would address bug 59160.