When writing a bug report, please include a brief, relevant title. 

The title should say what the *expected* behavior *should be*. Although it is useful to describe what is broken, this approach is fraught with two perils. First, please include sufficient information and not just e.g. "the table is broken". Secondly, please say what is the expected correct behavior, rather than what is broken. E.g., if you say "the table shouldn't sort by date" then the engineer who will fix it will have to spend extra effort discovering how it should behave: should it sort by name, ascending? Should it sort by id, descending? Even when an error is glaringly obvious, the right fix usually has to be described independently of the problem. So, it is best to use the title to briefly and relevantly describe that the functionality *should be*, rather than how exactly it is broken.

Importantly, every bug report should have three pieces: steps to reproduce, expected outcome, actual outcome.

### Steps to reproduce:
e.g.

* login a standard user
* open SearchModal, write "any" in the name field, click "run"
* open QueriesModal, click to modify a query
* click "save" to finish modifying

### Expected result:
e.g.

the results should be empty and the results title should say "no results"

### Actual result:
e.g.

The results table is unchanged and still shows some number of results from the previous search.

Of note, not all of the above information is actually relevant and required for every bug report, but it is really helpful to think of these three pieces as required. Missing information will inevitably lead to further questions from the engineers - so it saves everyone time to add that info from the beginning.

Importantly, in screenshots, please include the URL of every page, in every screenshot.  The url is often very, very important and just having a screenshot of the page, without the url, often does not provide sufficient information to fix a problem.