I spent some time yesterday reviewing bugs. I had some problems with searching the bugtracking page that as far as I'm concerned show it's not up to par. The bug tracker is obviously heavily used, which means it must be useful. I wonder what thought, if any, has been given to using a better one. 1. To filter on a value in a column, you can click on the column heading, check 1 or more labels, and press OK at the bottom of the dialog. If I check "GC 3.x" (for which the dialog says there are 31 items presently), and OK, it returns 121 results, including many that are not 3.x, such as #590, which is GC 2.2. 2. Using the search syntax, I tried _milestone:"GC 3.1" and !status:closed That returned 16 results, including #419 which, interesting as it is, is tagged GC 4.0. 3. Under the Status column, one can choose among 5 statuses, none of which is "closed". Evidently the set of filterable statuses does not equal the set of statuses. 4. Suppose you were interested in security-related bugs. That's not a status or milestone, or any other property. Maybe you vaguely remember there's a bug related to CVE-2019-16395, but not its number (#586). How are you supposed to find it? Entering "CVE-2019-16395" in the search won't turn it up, nor will "CVE". 5. It's nice there's a standard search grammar. It's not as nice that the (configurable) fields that might be referred to in the grammar aren't mentioned anywhere I could find. It seems as though SF expects the user to have access to the underlying tracking system's configuration. 6. Like the rest of SF, it's slow. Slow is better than broken, but slow doesn't improve broken. Many better systems exist. --jkl
