Bug search doesn't make it obvious that you're searching on projects

[Stephen Gornick]

When I try to search bugs for Ubuntu Automake, I cannot select the right project in Launchpad because it doesn't appear in the list of projects. If I search using the keyword "automake" for the project I can choose a "Product" automake, but the project Ubuntu Automake1.7 doesn't appear. I even tried the keywords "ubuntu automake", "automake1.7", "ubuntu automake" and "ubuntu automake1.7", none of which will yield the "Ubuntu Automake1.7" project.

When I then select Automake "product", then click on Report a Bug, then I am warned that Automake doesn't use Launchpad, and am prompted to select the "Ubuntu Automake1.7" project. So Launchpad DOES know abut the project, just that the search results won't yield it using the obvious search keywords.

[Stephen Gornick (sgornick)]

The steps to replicate:
  https://bugs.launchpad.net/
  In the search field enter "automake"
  Select "One Project" and click on the link "Choose". In the "Select a project" dialog, enter into the search field "automake" (or any of the combinations as described above). The only result is Automake (Product).

[Curtis Hovey (sinzui)]

automake is a project (a history of source code), automake1.7 is a specific release (a source package) from that project that is on a distribution. While bugs can be tracked to specific versions, they are are. Most bugs live for many versions, so they are tracked in distribution by the general package name (automake in the case of ubuntu).

The form is intended for users to locate an issue in a general area. There is not enough information about what users are trying to search from that page. Since you know you are interested in an Ubuntu package, you should be searching the ubuntu project (eg you know you do not care about bugs in baltix) Search will provide result restricted to the package

[Graham Binns (gmb)]

I think that this bug could be solved by either:

 a) Making the documentation on the search page better so that the problem here is obviated by the search being explained better.
 b) Making the search more DWIM (where WIM refers to the use-case in this bug).

I think that a) is the better option, so I'm updating the bug to match.