---
id: productivity-linear-jira-workflow
title: Issue Tracking — Linear / Jira / GitHub Projects
category: Coding
status: draft
source_trust_level: B
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
tags: [productivity, project-management, vibe-coding]
tech_stack: { language: "process", applicable_to: ["Engineering"] }
applied_in: []
aliases: [Linear, Jira, GitHub Projects, kanban, sprint, workflow, triage, issue tracking]
---

# Issue Tracking & Workflow

> Issue / task tracker = 팀 의 brain. **Linear (modern), Jira (enterprise), GitHub Projects, Notion, Trello**. 좋은 workflow ↑ throughput.

## 📖 핵심 개념
- Single source of truth.
- 명시적 status (Backlog / In progress / Done).
- WIP (Work in Progress) 제한.
- Triage (incoming → priority).

## 💻 코드 패턴

### Linear (modern, 빠름)
```
Workspace → Team → Project → Issue
- Cycles (sprint 식)
- Roadmap
- Triage queue
- Auto-archive

Hotkey-friendly. CMD+K 가 모든 것.
```

### Jira (enterprise, 무거움)
```
Project → Epic → Story → Sub-task
- Custom fields
- Workflow editor
- Plugin marketplace
- 큰 enterprise

Slow + complex.
```

### GitHub Projects (v2)
```
- Issue + PR 가 native
- Custom field, view (table/board/roadmap)
- Saved view
- Automation (PR open → status change)

→ 코드 와 가까움. 작은-중간 팀.
```

### Workflow (status)
```
일반:
Triage → Backlog → Up Next → In Progress → In Review → Done

또는:
Idea → Spec → Design → Build → Ship → Done
```

### Triage
```
새 issue 가 Triage queue.
→ EM / TL 가 weekly:
- Priority (P0-P4)
- Estimate
- Assign / team
- Backlog 또는 close

→ Inbox-zero 식.
```

### Priority
```
P0: 긴급 (down, security)
P1: high (release blocker)
P2: medium (이번 sprint)
P3: low (someday)
P4: nice-to-have
```

### Cycles (Linear) / Sprints
```
2 주 cycle.
- Plan (Mon)
- Work (2 weeks)
- Review + retro (Fri 마지막)

→ Cycle 끝 = 진행 중 인 만큼 다음 cycle.
```

### Backlog grooming
```
Weekly 30 min.
- Stale issue 닫기
- 새 idea 정리
- Priority 조정
- Estimate (story point 또는 hour)
```

### WIP limit
```
Per person: 2-3 in-progress.
Per team: 5-10.

→ Multitasking ↓ throughput.
```

→ Kanban 의 핵심.

### Issue template
```markdown
## Problem
What's broken / missing.

## Acceptance criteria
- [ ] X works
- [ ] Y is documented

## Out of scope
What we're NOT doing.

## Related
#1234, [doc link]
```

→ 가짜 issue (vague) 가 backlog 채움 방지.

### Bug template
```markdown
## Reproduction
1. Open page X
2. Click Y
3. See error

## Expected
Z happens.

## Actual
Q happens.

## Environment
- Browser: Chrome 120
- OS: macOS 15
- App version: 1.5.2

## Logs / screenshots
[paste]
```

### Issue → PR 연결
```markdown
<!-- PR description -->
Closes #123, #456
```

→ Merge 시 issue 자동 close.

```markdown
Linear: closes ENG-1234
GitHub: closes #123
Jira: ABC-1234
```

### Branch naming
```
{type}/{issue-id}-{slug}

feat/ENG-1234-add-oauth
fix/ENG-2345-login-redirect
```

→ Auto-link, hot-key navigation.

### Auto-status (Linear)
```
PR open → "In Review"
PR merged → "Done"
PR closed → "Cancelled"
```

→ Manual update X.

### Estimate
```
Story point: 1 / 2 / 3 / 5 / 8
T-shirt: XS / S / M / L / XL

→ Velocity tracking.
```

→ [[Productivity_Estimating_Effort]].

### Assignee
```
한 명 만 (책임).
- "TBD" = 진행 X.
- 변경 = 명시적.
```

→ Multiple owner = no owner.

### Subtask
```
Big issue → 4-8 subtask.
- 매 subtask = 1 PR.
- Visible 진행.

→ "1 large issue 가 1 month" 보다 "10 subtask 가 1주" 가 visible.
```

### Project (Linear)
```
관련 issue 묶기 (epic 비슷).
- 시작 / 끝 시기
- Owner
- Health (on track / off / blocked)
- Roadmap 가 시각화
```

### Roadmap
```
Quarter 별 project.
Q2 2026:
- Auth refactor (Engineering)
- Mobile app (Mobile)
- Analytics dashboard (Data)
```

### Customer feedback link
```
Feature request → issue.
Customer name + use case.

→ 우선순위 결정 시 customer count.
```

### Linear's "shortcut" (Linear 의 idea)
```
Cycle 끝 = stale issue close (4 weeks 안 변경).
→ Backlog 가 무한 안 됨.
```

### GitHub Issues + Projects
```yaml
# .github/ISSUE_TEMPLATE/bug.yml
name: Bug
description: Report a bug
labels: ['bug']
body:
  - type: markdown
    attributes:
      value: '## Bug Report'
  - type: textarea
    id: reproduction
    attributes:
      label: Reproduction
      description: Steps to reproduce
    validations: { required: true }
```

### Custom field
```
- Priority (enum)
- Estimate (number)
- Team (enum)
- Customer (text)
- Sprint (iteration)
```

→ Saved view 가 filter.

### Automation
```
- Issue closed → Slack notify
- PR merge → status change
- 7 days no activity → reminder
- Stale label → auto close
```

### Slack 통합
```
- /linear ENG-123 → preview
- 새 P0 → channel
- Issue mention → auto-link
```

### Daily standup (async)
```
매일 매 사람 가 Slack:
- Yesterday: 한 거
- Today: 할 거
- Blocker: 막힌 거

→ Synchronous standup 보다 timezone-friendly.
```

### Retro (cycle 끝)
```
What went well?
What didn't?
What to try next cycle?

→ 30 min, 명시적 action items.
```

### Blocker tracking
```
Issue 의 blocker:
- 다른 issue (dep)
- 외부 (legal, design, ...)
- 정보 부족

→ 명시적 mark. Cycle 끝 = "가능한 거 못 한 이유?"
```

### Search / filter
```
Linear:
"P0 in current cycle and assignee:@alice and status:in-progress"

→ Saved view 가 매번 검색 X.
```

### 작은 팀 (시작)
```
첫 6 month: GitHub Issues 만.
6-12 month: GitHub Projects 추가.
1+ year, 5+ engineer: Linear / Jira.
```

→ Tooling 가 비즈니스 따라 grow.

### Linear vs Jira 가격
```
Linear: $8-14/user/month
Jira: $7-15/user/month
GitHub Projects: 무료 (with GitHub)
```

### Best practices
```
1. Issue 의 acceptance criteria
2. WIP limit
3. Single assignee
4. Backlog grooming
5. Stale auto-close
6. PR 가 issue 와 연결
7. Standups async
```

## 🤔 의사결정 기준
| 팀 | 추천 |
|---|---|
| 1-5 person | GitHub Issues |
| 5-50, modern | Linear |
| 50+ enterprise | Jira |
| 비-engineering | Asana / Notion |
| Open source | GitHub Issues + Discussions |
| Customer-facing | Customer dashboard + sync |

## ❌ 안티패턴
- **Backlog 무한**: 1000+ open issue.
- **No triage**: 우선순위 모름.
- **Multiple assignee**: no owner.
- **Vague title**: "fix bug".
- **No acceptance criteria**: "done"" 의미 모름.
- **Manual status**: 매번 잊음.
- **Slack 만 + 추적 X**: 잊혀짐.

## 🤖 LLM 활용 힌트
- Linear / GitHub Projects 가 modern default.
- Triage queue 가 backlog hygiene.
- WIP limit + cycle 가 throughput.
- Single assignee + acceptance criteria.

## 🔗 관련 문서
- [[Productivity_Code_Review]]
- [[Productivity_Estimating_Effort]]
- [[Productivity_PR_Template]]
