Field Taxonomy¶
Every YouTrack issue carries a set of fields that describe what it is, how urgent it is, who owns it, and where it fits in the workflow. This page explains each field — not just the values, but when and why to use them.
For a quick overview, here's the full schema. Each field is explained in detail below.
| Field | Type | Values |
|---|---|---|
| Type | enum | Bug, Epic, User Story, Task |
| State | enum | Open, In Progress, Review, Done, Duplicate, Proposal, Invoice |
| Priority | enum | Show-stopper, Critical, Major, Normal, Minor |
| Category | single-select | Product, Production, Infrastructure, Research, Business, Sales |
| Complexity | single-select | Trivial, Small, Medium, Large, Unknown |
| Production State | single-select | Requirements, Preparation, Execution, Dataset Creation, Review, Delivered |
| Tags | multi-value | backend, frontend, compute, devops, design, creative, account, admin |
| Estimation | period | w d h m format |
| Assignee | user | Single user |
| Reviewer | user | Single user |
| Sprint | multi-value | Sprint names |
Type¶
Required — set at creation. Determines the issue template and how the issue is treated on boards and in reports.
| Value | When to use |
|---|---|
| Bug | Something is broken. Observed behavior doesn't match expected behavior. Has a clear "it works" / "it doesn't" signal. |
| User Story | A new capability described from the user's perspective. Follows the "As a [role], I want [X], so that [Y]" pattern. Use when the why matters as much as the what. |
| Task | Prescriptive work where the writer already knows what needs to be done. Engineering tasks, operational work, configuration changes. No need for the user story framing. |
| Epic | A goal that decomposes into multiple child issues. Epics are containers — they don't get assigned to developers directly. They track progress across their subtasks. |
Common mistake: Using Task when you mean User Story. If the issue describes a capability that someone will use, it's a User Story. If it describes work to be done, it's a Task. "Add export button to reports page" is a User Story. "Migrate reports table to new schema" is a Task.
State¶
Required — defaults to Open. Tracks where the issue is in its lifecycle. See Workflows for the full state machine and transition rules.
| Value | Meaning | Who moves it here |
|---|---|---|
| Open | Ready to be picked up. Either newly created or returned from another state. | Issue creator, sprint planner, or anyone unblocking it |
| In Progress | Someone is actively working on this right now. | The assignee, when they start work |
| Review | Work is complete and waiting for review — code review, QA, stakeholder sign-off, or creative approval. | The assignee, when they're done with implementation |
| Done | Accepted, merged, deployed, or otherwise complete. The issue is closed. | The reviewer, after approval |
| Duplicate | This issue describes the same problem or request as another issue. Should link to the original. | Anyone who spots the duplicate |
| Proposal | An idea or request that hasn't been validated yet. Proposals need approval before becoming actionable work. Use this for rough captures that need formalization. | Issue creator (for unvalidated ideas), or backlog maintainer |
| Invoice | The work is done and the deliverable is billable. Used for production and client-facing work that needs to be invoiced. | Project manager or backlog maintainer |
Tip: If you're not sure whether something is ready to be Open or should be a Proposal first, default to Proposal. It's easier to promote a Proposal to Open than to deal with half-baked Open issues cluttering the sprint board.
Priority¶
Required — defaults to Normal. Signals urgency and determines the order in which issues should be addressed within a sprint.
| Value | Meaning | Response expectation |
|---|---|---|
| Show-stopper | The system is down, data is being lost, or a critical business function is blocked. Everything else stops. | Drop what you're doing. |
| Critical | Severe impact on users or business, but not a total outage. Needs to be resolved in the current sprint. | Top of the sprint. |
| Major | Significant issue that affects a meaningful number of users or blocks other work. | Current sprint, planned. |
| Normal | Standard work. Most issues live here. | Sprint-planned, normal queue. |
| Minor | Nice-to-have, polish, low-impact improvements. Fine to defer if the sprint is full. | When there's bandwidth. |
Calibration guide: Priority should reflect impact, not effort. A 5-minute fix can be Show-stopper if it's blocking production. A 2-week feature can be Minor if nobody is waiting for it.
Category¶
Optional — auto-filled from the project default (see Projects), but can be overridden per issue.
Categories describe what area of the business an issue relates to. They cut across projects — an OPS issue could be categorized as Product if it's infrastructure for the product.
| Value | Scope |
|---|---|
| Product | Core platform features, user-facing functionality. Default for SAR and IDQ projects. |
| Production | Photo shoots, creative work, deliverables for clients. Work that flows through the Production State lifecycle. |
| Infrastructure | Servers, CI/CD, monitoring, developer tooling. Default for OPS project. |
| Research | Experiments, evaluations, prototypes. Default for LAB project. |
| Business | Business operations — contracts, partnerships, process improvements. Non-technical work that still needs tracking. |
| Sales | Sales pipeline support — demos, proposals, client-specific requests. |
When to override the default: If an issue in SAR is really about infrastructure (e.g. "set up staging environment for SAR"), change Category to Infrastructure even though SAR defaults to Product.
Complexity¶
Optional — defaults to Unknown. Set during sprint planning to help with capacity allocation.
| Value | Rough meaning | Typical estimation |
|---|---|---|
| Trivial | Config change, one-liner, copy fix. Could be done in a coffee break. | < 1h |
| Small | Well-understood change, limited scope, touches 1-2 files. | 1h – 4h |
| Medium | Requires some design thinking, touches multiple files or systems, needs testing. | 4h – 2d |
| Large | Significant feature work, requires architectural decisions, cross-team coordination, or extended testing. Consider breaking into smaller issues. | 2d – 1w |
| Unknown | Not yet analyzed. Needs refinement before it can be estimated. | Sprint planning required |
Complexity vs Estimation: Complexity is a t-shirt size for planning discussions. Estimation is the actual time budget. Use Complexity for quick prioritization; fill in Estimation when you commit the issue to a sprint.
Production State¶
Optional — only relevant for issues with Category = Production. Tracks the lifecycle of creative and production work, which follows a different flow than engineering.
| Value | Phase |
|---|---|
| Requirements | Gathering the brief — what needs to be produced, specs, references, guidelines. |
| Preparation | Setting up for execution — sourcing assets, configuring tools, scheduling. |
| Execution | The production work is happening — shooting, rendering, generating. |
| Dataset Creation | Post-production data work — labeling, annotation, quality control. |
| Review | Output is ready for review — creative approval, client feedback, QC check. |
| Delivered | Final deliverables handed off to the client or internal stakeholder. |
Leave this field blank for engineering issues. It only appears on boards when filtered by Category = Production.
Tags¶
Optional, multi-value. Tags describe what technical area an issue touches. They power board filters, reports, and help developers find relevant work.
| Tag | Area |
|---|---|
| backend | Python, FastAPI, SQLAlchemy, API endpoints, server logic |
| frontend | TypeScript, React, Next.js, UI components, styling |
| compute | GPU workloads, GenAI pipelines, model inference, image processing |
| devops | CI/CD, Docker, deployment, monitoring, infrastructure-as-code |
| design | UI/UX design, mockups, wireframes, design system |
| creative | Photography, art direction, visual content, brand assets |
| account | Account management, user administration, permissions |
| admin | Internal admin tools, back-office features |
Apply as many tags as relevant — an issue can be both backend and compute if it involves API endpoints for GPU workloads. Tags are additive, not exclusive.
Estimation¶
Optional — set during sprint planning. The time budget for completing the issue.
Format: w d h m (weeks, days, hours, minutes). Combine units as needed:
| Example | Meaning |
|---|---|
2h |
2 hours |
1d |
1 day (= 8 working hours) |
1w 2d |
1 week and 2 days |
3h 30m |
3 hours 30 minutes |
Guidelines:
- Prefer round numbers:
2h,1d,3d— not1h 47m. False precision wastes time. - If an issue estimates above
1w, it's probably too large. Break it into subtasks. - Estimation feeds the sprint burndown chart and capacity planning. Unestimated issues in a sprint create blind spots.
Assignee¶
Optional — a single user. The person responsible for completing the work.
Set the Assignee when:
- You're creating an issue and know who should do it
- During sprint planning, as part of capacity allocation
- When picking up an issue yourself (assign to
mevia the command bar)
Unassigned issues in a sprint should be flagged during standups.
Reviewer¶
Optional — a single user. The person responsible for reviewing and approving the work.
Set the Reviewer when the issue enters the Review state. This is typically:
- The person who will review the pull request (engineering)
- The creative director or client contact (production)
- The project lead for cross-cutting work
The Reviewer is the person who moves the issue from Review → Done.
Sprint¶
Optional, multi-value. The sprint(s) this issue is scheduled in.
Issues can belong to multiple sprints — this happens when work carries over from one sprint to the next. The current sprint is always the active one on the agile board.
Sprint names are descriptive, reflecting the sprint goal (e.g. "Customer Shooting Guidelines"). See Workflows for sprint lifecycle details.
Set sprints during sprint planning, either by dragging issues on the board or via the command bar: sprint Sprint Name.