> For the complete documentation index, see [llms.txt](https://docs.imerit.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.imerit.net/core-concepts/review-queue.md). # Review Queue The review queue is the list of [tasks](/core-concepts/tasks.md) that are distributed to reviewers, in order. If your project's workflow has multiple review stages, each stage will have its own queue. ## Using the Review Queue From the dashboard, click on the *Start Reviewing* button on the top-right. You will be shown the first review task that is available to you from one of the review queues. If your project has more than one review queue, the queue will be picked at random. Once you review it and click on *Accept* or *Reject*, you will be shown the next, and so on. {% hint style="info" %} You may choose to review a certain task without following queue order by going to the *Task* tab and clicking on any task, or by clicking on a circle under the *Labels* column in the *Assets* tab. Doing so does not invoke the review queue, and reviewing the asset will not move you forward one task. Essentially, you will only review that one particular task. {% endhint %} ### Properties of the Review Queue * The task at the top of the queue is the task that will be shown next to reviewers in the stage. * Each project has one review queue for each *Review* stage in your [workflow](/core-concepts/workflow.md). When reviewers open a task, they pick from the top of the queue the first task that is unassigned or assigned to them. * All tasks in a *Review* stage are automatically part of a labeling queue. * Tasks get added to the bottom of the queue as they are created. Thus, the queue is ordered by task creation time, first in first out. * Tasks that have been assigned to user X (for example, X is currently reviewing them) will be unavailable to Y. Y will be given the next task in the queue that is unassigned or assigned to them. Whenever users press on the *Start Reviewing* button on the top-right corner of the dashboard, they are shown the first task in the review queue. When they complete reviewing and press on *Accept/Reject*, they pick another task from the top of the queue, and so on. {% hint style="info" %} If the project has multiple review queues as a result of having more than one *Review*-type stage, clicking on *Start Reviewing* will choose one of the labeling queues at random. If you wish to review in a particular queue, click on the downward-facing chevron next to the *Start Reviewing* button a pick a particular queue you'd like to work on. {% endhint %} Project managers can optionally display the number of tasks waiting in Label and Review queues. See [Showing Queue Task Counts](/core-concepts/labeling-queue.md#showing-queue-task-counts) for setup and behavior. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.imerit.net/core-concepts/review-queue.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.