Step 4 of 5
Submission Workflow
Learn how to submit your work and move tasks through the pipeline.
How tasks move through the platform
Every task follows a defined lifecycle from the moment you claim it to the moment it is approved and archived. Understanding this workflow is essential — it tells you what to do, when to do it, and what happens if something goes wrong.
Based on Henna. This guide describes the submission workflow as it works on annotation-platform-henna. The core concepts — claiming, saving, submitting, releasing, and handling send-backs — apply to Featheras well, though interface details and exact button names may differ. Always check your project's onboarding materials for platform-specific guidance.
01How the Queue Works
Tasks live in a shared queue for each project you are assigned to. When a task becomes available, the platform assigns it to the next eligible contributor who clicks Start Tasking. Normally, the system select a task for you based on your role, skill level, and current queue state, though sometimes you might be able to choose, depending on the project needs.
Task Lifecycle
Tasks have time limits
Each task has a specific time allocation. Time expectations are defined by the project and can vary by task layer (for example, attempter vs reviewer). Always follow the timing guidance documented for your current project.
02Claiming a Task
To claim your next task, navigate to the project dashboard and click the Start Tasking button. The platform typically assigns you the next available task, which then opens in your browser.
Start Tasking
Click this button under any assigned project to claim your next task. The task opens immediately so you can begin working.
In many projects, contributors work on one active task at a time. If you already have a task in progress, Start Tasking may return you to it instead of assigning a new one. Follow the behavior and guidance for your current project.
Before clicking Start Tasking, make sure you have enough uninterrupted time to complete the task. Claiming a task and then pausing for long periods can delay overall queue flow.
03Working & Saving Progress
Once you have a task open, work through it carefully. Read all the task content before starting — many tasks have context later in the page that changes how you should approach the beginning.
Save
Saves your current progress without submitting. Use this if you need to take a break, close the browser, or step away mid-task. Your work is preserved and you can return to it later.
Best Practices While Working
- Save frequently — do not risk losing progress to a browser crash or accidental close
- Re-read the instructions whenever you are unsure about a specific part of the task
- Complete the full task in one sitting when possible — context is harder to recover if you return later
- If the task has multiple parts, complete each one before moving to the next
04Submitting Your Work
When your work is complete and you are confident in its quality, click Submit Task. Submission moves the task to the next stage — it either enters the reviewer queue immediately, or is held briefly while the platform matches it with an available reviewer.
Submit Task
Finalizes your work and sends it to the next stage. Once submitted, you cannot edit the task unless it is sent back to you by a reviewer.
What happens after you submit
Task enters reviewer queue
A reviewer is assigned and receives your submission for evaluation.
Reviewer evaluates
They check your work against the task instructions and quality criteria.
Approved
Your work passes. The task is marked complete and archived in the dataset.
Sent back to queue
The reviewer found issues. The task returns to you with feedback. See Section 06.
Submission is final until review. Once you click Submit, your work is locked. If you realize you made a mistake after submitting, you cannot fix it until a reviewer sends it back. This is why careful review before submission matters.
05Releasing (Unclaiming)
Release (also called Unclaim) returns a task to the shared queue without submitting it. Another contributor can then pick it up. This is the correct action when you receive a task you genuinely cannot complete — not a task that is difficult or time-consuming, but one that requires knowledge or access you don't have.
Release / Unclaim
Returns the task to the queue, unsubmitted. Use this when you genuinely cannot complete the task, not as a way to skip difficult work.
Good reasons to release
- The task requires domain knowledge you do not have
- You do not have access to a required tool or environment
- The task is in a language you cannot work in
Reasons that do not justify release
- The task is hard or takes longer than expected
- You want a different (easier) task instead
- You are not prepared to continue working on it at that moment
Projects may review release patterns over time. Frequent releases can indicate a mismatch between task requirements and current availability or readiness.
06Send Back to Queue
A Send Back to Queue (SBQ) means a reviewer evaluated your submitted work and determined it did not meet the required standard. The task is returned to you — not to the general queue — with the reviewer's feedback explaining what needs to be fixed.
What an SBQ means
Your submission was reviewed and rejected. The reviewer found one or more issues that prevent the task from being approved. The task is now back in your queue with specific feedback — your job is to read that feedback carefully, fix the identified issues, and resubmit.
How to Handle an SBQ
Read the reviewer's feedback in full
Do not skim it. The feedback explains exactly what was incorrect. Missing a point often results in another return.
Re-read the task instructions
Often, SBQs happen because the instructions were not followed precisely. Go back to the source before making changes.
Fix every issue mentioned
Do not fix only the most obvious issue. If the reviewer listed three issues, all three must be addressed before resubmitting.
Resubmit promptly
After addressing all feedback points, resubmit as soon as the task is ready.
Repeat SBQs are serious
A single SBQ is a correction opportunity. Multiple SBQs on the same task — or a pattern of SBQs across tasks — indicates a systemic quality issue and will trigger a review of your standing on the project.
07Task Priority
Not all tasks have equal priority. The order below is a common framework, but project-specific guidance should take precedence.
Send Back to Queue tasks
Tasks returned by reviewers are often time-sensitive because they are already in the review pipeline. In practice, many teams prioritize these tasks so feedback loops stay short. Follow your project lead's priority guidance.
Time-sensitive tasks
Some projects designate certain tasks as higher priority based on timelines or operational needs. Your project lead or project channels will communicate those priorities.
Normal queue
Regular tasks from the standard project queue. These are typically first-come-first-served. Work through them steadily while maintaining high quality.
If you are ever unsure which task to work on first, check your project's Slack announcements channel. The project lead will post priority updates there when the workload changes.
When in doubt about a task, ask in your project's Slack channel before releasing or submitting with uncertainty.