Logical Conditions

Just like in GitHub, all query terms are implicitly combined with a logical and. But you can also combine queries using OR and NOT, such as:

org:dotnet (author:terrajobst OR author:jaredpar) NOT (label:api-ready-for-review OR label:api-needs-work)

This will show all issues in the dotnet org that were created by either terrajobst or jaredpar, and aren't labelled as api-ready-for-review or api-needs-work.

Like in GitHub, you can also use the simple - prefix instead of NOT, so this will show all open issues that aren't labelled as bugs:

is:open is:issue -label:bug

Do not combine query terms using AND. Multiple terms are always combined with a logical and unless you use OR. A specified AND will be interpreted as a text filter (i.e. it will only match issues that contain the word AND).

Relative Dates

Standard GitHub supports range queries like created:>2012-01-05 and created:2012-01-05..2012-01-30. Here you can also use relative dates like @today, @today-{days} and @today+{days}.

For example, this shows all non-draft PRs that were created 30 days ago and weren't updated in the last 10 days:

is:open is:pr -is:draft repo:dotnet/runtime created:<@today-30 updated:<@today-10 sort:updated-asc

Grouping

You can group issues by various fields, such as assignee. For example, the following query will produce a list of all open non-draft PRs grouped by assignee, starting with the person that has the most open PRs. In the result query, you can expand each group to drill into the issues.

is:open is:pr repo:runtime -no:assignee -is:draft group:assignee group-sort:count-desc

You can also group by multiple fields.

When you group by fields that have multiple values per issue, the resulting issue might show up multiple times. For example, when you group by assignee, an issue that is assigned to two people will show up under each person.

Area Paths

Areas are taken from labels that start with area- (casing doesn't matter). Inside an area path, anything that isn't a a digit or letter is considered a separator. So a label area-CodeGen-Mono is interpreted as an area path of CodeGen-Mono which has two nodes CodeGen and Mono.

We have three ways to match areas:

area:{area-path}

Only shows issues with a label of area-{area}, equivalent to label:area-{area}

area-under:{area-path}

Only shows issues with any label of the form area-{area}*, that is it includes other labels with that prefix

area-node:{area-node}

Only shows issues with any label of the form area-*{area}*

The first two take an area path, such as System.Runtime.InteropServices. Let's say you have 1 issue that is labelled with area-System.Runtime and two other issues that are labelled with area-System.Runtime.InteropServices. Here is what these queries would return:

Query	#Results
area:System	0
area:System.Runtime	1
area:System.Runtime.InteropServices	2
area-under:System	3
area-under:System.Runtime	3
area-under:System.Runtime.InteropServices	2
area-node:System	3
area-node:Runtime	3
area-node:InteropServices	2

To search for issues and PR's that don't have any label, use the same no: syntax that you would use in GitHub: no:area.

Area Owners

If a repo has an area-owners.md file (like dotnet/runtime) you can also use area-owner and area-lead.

For example, this shows all PRs in areas where jeffhandley is the lead:

is:open is:pr area-lead:jeffhandley

This shows all PRs for areas where bartonjs is an area owner for:

is:open is:pr area-owner:bartonjs