Use Labels and Tags Effectively | Filtering Guide
Organize work with labels for priority, type, and component. GitScrum enables powerful filtering, reporting, and workflow automation with consistent tagging.
10 min read
Labels and tags transform a flat list of tasks into a multi-dimensional system that enables instant filtering, accurate reporting, and workflow automation. GitScrum's labeling capabilities let you categorize work by priority, type, component, team, and any custom dimension your workflow requires. The key is establishing a consistent taxonomy that the entire team uses reliably, avoiding label sprawl that creates confusion.
Label Strategy
Designing Your Taxonomy
BUILDING A LABEL SYSTEM:
┌─────────────────────────────────────────────────────────────┐
│ LABEL CATEGORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESSENTIAL CATEGORIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. PRIORITY (how urgent) ││
│ │ 🔴 critical – Drop everything ││
│ │ 🟠 high – This sprint, important ││
│ │ 🟡 medium – Planned work ││
│ │ 🟢 low – Nice to have ││
│ │ ││
│ │ 2. TYPE (what kind of work) ││
│ │ 🐛 bug – Something broken ││
│ │ ✨ feature – New capability ││
│ │ 🔧 improvement – Making existing better ││
│ │ 📚 docs – Documentation ││
│ │ 🧹 chore – Maintenance, cleanup ││
│ │ 🔬 spike – Research, investigation ││
│ │ ││
│ │ 3. STATUS (workflow state beyond columns) ││
│ │ 🚧 blocked – Can't proceed ││
│ │ 👀 needs-review – Awaiting review ││
│ │ ✅ ready – Ready to start ││
│ │ 🔙 returned – Sent back for changes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CONTEXTUAL CATEGORIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 4. COMPONENT (where in codebase) ││
│ │ frontend, backend, api, database, mobile ││
│ │ auth, payments, notifications, analytics ││
│ │ ││
│ │ 5. EFFORT (size estimation) ││
│ │ xs (< 1 hour) ││
│ │ s (1-4 hours) ││
│ │ m (1-2 days) ││
│ │ l (3-5 days) ││
│ │ xl (1+ weeks) ││
│ │ ││
│ │ 6. AUDIENCE (who benefits) ││
│ │ internal, customer-facing, partner ││
│ │ enterprise, small-business ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Naming Conventions
LABEL NAMING BEST PRACTICES:
┌─────────────────────────────────────────────────────────────┐
│ CONSISTENT NAMING │
├─────────────────────────────────────────────────────────────┤
│ │
│ USE PREFIXES FOR GROUPING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Format: category/value ││
│ │ ││
│ │ priority/critical ││
│ │ priority/high ││
│ │ priority/medium ││
│ │ priority/low ││
│ │ ││
│ │ type/bug ││
│ │ type/feature ││
│ │ type/improvement ││
│ │ ││
│ │ component/frontend ││
│ │ component/backend ││
│ │ component/mobile ││
│ │ ││
│ │ Benefits: ││
│ │ • Labels sort together alphabetically ││
│ │ • Easy to filter by category ││
│ │ • Clear what dimension each label represents ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NAMING RULES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ DO: ││
│ │ • Use lowercase: priority/high ││
│ │ • Use hyphens for multi-word: good-first-issue ││
│ │ • Be specific: component/auth-service ││
│ │ • Use nouns or adjectives, not verbs ││
│ │ ││
│ │ ❌ DON'T: ││
│ │ • Mixed case: Priority/High ││
│ │ • Spaces: "priority high" ││
│ │ • Vague: misc, other, stuff ││
│ │ • Duplicative: bug, bugs, bug-fix, bugfix ││
│ │ • Too long: this-is-a-very-long-label-name ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Color Coding
Visual Hierarchy
COLOR STRATEGY:
┌─────────────────────────────────────────────────────────────┐
│ USING COLORS EFFECTIVELY │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRIORITY COLORS (intuitive traffic light): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Red – Critical, urgent ││
│ │ 🟠 Orange – High, important ││
│ │ 🟡 Yellow – Medium, normal ││
│ │ 🟢 Green – Low, can wait ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TYPE COLORS (semantic meaning): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Red – Bug (something wrong) ││
│ │ 🟣 Purple – Feature (new thing) ││
│ │ 🔵 Blue – Improvement (better thing) ││
│ │ 🟤 Brown – Documentation ││
│ │ ⚫ Gray – Chore (maintenance) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STATUS COLORS (attention level): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Red – Blocked (needs attention!) ││
│ │ 🟡 Yellow – Needs review (action required) ││
│ │ 🟢 Green – Ready (good to go) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMPONENT COLORS (team association): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Use distinct colors for each component/team ││
│ │ Keep consistent across all projects ││
│ │ ││
│ │ 🔵 Blue – Frontend ││
│ │ 🟢 Green – Backend ││
│ │ 🟣 Purple – Mobile ││
│ │ 🟤 Brown – Infrastructure ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Filtering and Reporting
Power Filtering
USING LABELS FOR FILTERING:
┌─────────────────────────────────────────────────────────────┐
│ FILTER COMBINATIONS │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMMON FILTER PATTERNS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "What bugs need attention?" ││
│ │ Filter: type/bug + priority/high ││
│ │ ││
│ │ "What's blocked right now?" ││
│ │ Filter: status/blocked ││
│ │ ││
│ │ "What frontend work is ready?" ││
│ │ Filter: component/frontend + status/ready ││
│ │ ││
│ │ "What small tasks for new developers?" ││
│ │ Filter: effort/xs OR effort/s + good-first-issue ││
│ │ ││
│ │ "What features are customer-facing?" ││
│ │ Filter: type/feature + audience/customer-facing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SAVED FILTERS IN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Create saved views for common filter combinations: ││
│ │ ││
│ │ "Bugs This Sprint" ││
│ │ → type/bug + current sprint ││
│ │ ││
│ │ "My High Priority" ││
│ │ → assigned:me + priority/high OR priority/critical ││
│ │ ││
│ │ "Ready for Dev" ││
│ │ → status/ready + no assignee ││
│ │ ││
│ │ "Blocked Work" ││
│ │ → status/blocked ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Reporting and Metrics
LABEL-BASED INSIGHTS:
┌─────────────────────────────────────────────────────────────┐
│ ANALYTICS FROM LABELS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BUG TRACKING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Track: type/bug labels over time ││
│ │ ││
│ │ Metrics: ││
│ │ • Bugs opened vs closed per sprint ││
│ │ • Bugs by component (where are problems?) ││
│ │ • Bugs by priority (severity distribution) ││
│ │ • Bug resolution time (critical vs low) ││
│ │ ││
│ │ If component/payments has most bugs → investigate ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WORK TYPE DISTRIBUTION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Question: What % of sprint is new features vs bugs? ││
│ │ ││
│ │ Healthy sprint: ││
│ │ ┌────────────────────────────────────────────────┐ ││
│ │ │ Features ████████████████████░░░░░░░░░ 60% │ ││
│ │ │ Bugs ████████░░░░░░░░░░░░░░░░░░░░░ 20% │ ││
│ │ │ Improve ████░░░░░░░░░░░░░░░░░░░░░░░░░ 10% │ ││
│ │ │ Chores ████░░░░░░░░░░░░░░░░░░░░░░░░░ 10% │ ││
│ │ └────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Concerning sprint: ││
│ │ ┌────────────────────────────────────────────────┐ ││
│ │ │ Features ████░░░░░░░░░░░░░░░░░░░░░░░░░ 15% │ ││
│ │ │ Bugs ██████████████████████████░░░ 70% │ ││
│ │ │ ... │ ││
│ │ └────────────────────────────────────────────────┘ ││
│ │ → Technical debt problem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Workflow Automation
Label-Based Rules
AUTOMATING WITH LABELS:
┌─────────────────────────────────────────────────────────────┐
│ AUTOMATION TRIGGERS │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMMON AUTOMATION PATTERNS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TRIGGER: Label priority/critical added ││
│ │ ACTION: ││
│ │ • Notify #urgent-channel on Slack ││
│ │ • Assign to on-call rotation ││
│ │ • Move to top of board ││
│ │ ││
│ │ TRIGGER: Label status/blocked added ││
│ │ ACTION: ││
│ │ • Notify project manager ││
│ │ • Create daily reminder until unblocked ││
│ │ • Add to "Blockers" report ││
│ │ ││
│ │ TRIGGER: Label needs-review added ││
│ │ ACTION: ││
│ │ • Notify reviewers channel ││
│ │ • Start review timer ││
│ │ ││
│ │ TRIGGER: All checks pass on PR ││
│ │ ACTION: ││
│ │ • Add label status/ready-to-merge ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WITH GITSCRUM INTEGRATIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Connect to Slack/Teams/Discord: ││
│ │ • Specific labels trigger specific channels ││
│ │ • priority/critical → #incidents ││
│ │ • type/feature → #product-updates ││
│ │ ││
│ │ Connect to GitHub/GitLab: ││
│ │ • Sync labels between GitScrum and repo ││
│ │ • PR labels update task labels ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Governance
Preventing Label Sprawl
LABEL HYGIENE:
┌─────────────────────────────────────────────────────────────┐
│ KEEPING LABELS MANAGEABLE │
├─────────────────────────────────────────────────────────────┤
│ │
│ SPRAWL SYMPTOMS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ⚠️ 100+ labels in the system ││
│ │ ⚠️ Multiple labels meaning same thing ││
│ │ (bug, bug-fix, bugfix, bugs) ││
│ │ ⚠️ Labels not used in 3+ months ││
│ │ ⚠️ People create labels without asking ││
│ │ ⚠️ No one knows what some labels mean ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ GOVERNANCE RULES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. LIMIT WHO CAN CREATE: ││
│ │ Only team leads/PM can create new labels ││
│ │ Request process for new label proposals ││
│ │ ││
│ │ 2. DOCUMENT LABELS: ││
│ │ In NoteVault, maintain label glossary: ││
│ │ • Name ││
│ │ • Color ││
│ │ • When to use ││
│ │ • When NOT to use ││
│ │ • Examples ││
│ │ ││
│ │ 3. QUARTERLY AUDIT: ││
│ │ Review all labels: ││
│ │ • Delete unused labels ││
│ │ • Merge duplicates ││
│ │ • Rename unclear ones ││
│ │ ││
│ │ 4. TRAINING: ││
│ │ Onboarding includes label training ││
│ │ "Which labels for which situations" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TARGET: 30-50 labels maximum for most teams │
│ │
└─────────────────────────────────────────────────────────────┘
Special Label Patterns
Onboarding Labels
LABELS FOR NEW TEAM MEMBERS:
┌─────────────────────────────────────────────────────────────┐
│ ONBOARDING SUPPORT │
├─────────────────────────────────────────────────────────────┤
│ │
│ STARTER TASK LABELS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ good-first-issue ││
│ │ • Small, well-defined scope ││
│ │ • Clear acceptance criteria ││
│ │ • One new concept to learn ││
│ │ • Existing patterns to follow ││
│ │ ││
│ │ help-wanted ││
│ │ • Team welcomes outside contribution ││
│ │ • Context is well-documented ││
│ │ • Mentor available ││
│ │ ││
│ │ beginner-friendly ││
│ │ • No deep system knowledge needed ││
│ │ • Isolated from complex dependencies ││
│ │ • Good learning opportunity ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ONBOARDING WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ New developer searches: good-first-issue + status/ready ││
│ │ → Sees curated list of starter tasks ││
│ │ → Each task has clear context and mentor ││
│ │ → Progressive complexity: xs → s → m tasks ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘