8 min read • Guide 751 of 877
Using Labels Effectively in GitScrum
Labels help categorize and find work quickly. GitScrum's labeling system lets teams create custom taxonomies that match their workflow.
Label Strategy
What Labels Are For
EFFECTIVE LABEL USAGE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LABELS ARE GOOD FOR: │
│ │
│ ✅ CATEGORIZATION │
│ Type: bug, feature, improvement, docs │
│ Area: frontend, backend, api, infrastructure │
│ │
│ ✅ FILTERING │
│ "Show me all frontend bugs" │
│ "What's blocked right now?" │
│ │
│ ✅ VISIBILITY │
│ "urgent" label catches attention │
│ "needs-review" shows waiting items │
│ │
│ ✅ CROSS-CUTTING CONCERNS │
│ "tech-debt" spans all areas │
│ "quick-win" spans all types │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LABELS ARE NOT FOR: │
│ │
│ ❌ SINGLE VALUES (use custom fields) │
│ Priority: only one value → use field │
│ Sprint: only one value → use field │
│ │
│ ❌ COMPLEX DATA (use descriptions/fields) │
│ "deadline-jan-15" → use due date field │
│ "assigned-to-alex" → use assignee field │
│ │
│ ❌ TEMPORARY STATES (use status) │
│ "in-progress" → use workflow status │
│ "done" → use workflow status │
└─────────────────────────────────────────────────────────────┘
Label Taxonomy
RECOMMENDED LABEL CATEGORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TYPE (What kind of work): │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 🐛 bug │ Something is broken │ │
│ │ ✨ feature │ New functionality │ │
│ │ ⬆️ improvement│ Enhance existing feature │ │
│ │ 📄 docs │ Documentation only │ │
│ │ 🔧 chore │ Maintenance work │ │
│ │ 🧪 test │ Test-related work │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ AREA (What part of system): │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ frontend │ UI/UX work │ │
│ │ backend │ Server-side work │ │
│ │ api │ API endpoints │ │
│ │ database │ Data layer │ │
│ │ devops │ Infrastructure │ │
│ │ mobile │ Mobile app │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ STATUS (Special states): │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 🚫 blocked │ Waiting on external dependency │ │
│ │ 👀 needs-review│ Waiting for review │ │
│ │ ❓ needs-info │ Missing information │ │
│ │ 🔥 urgent │ High priority attention │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ EFFORT (Quick sizing): │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 🎯 quick-win │ < 30 minutes │ │
│ │ 📦 good-first-issue│ Good for new contributors │ │
│ │ 🏔️ epic │ Large multi-sprint effort │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Naming Conventions
Consistent Label Names
LABEL NAMING BEST PRACTICES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMAT: prefix:name │
│ │
│ EXAMPLES: │
│ type:bug │
│ type:feature │
│ area:frontend │
│ area:backend │
│ priority:critical │
│ status:blocked │
│ │
│ WHY PREFIXES: │
│ │
│ 1. GROUPING │
│ All "type:" labels sort together │
│ Easy to see label categories │
│ │
│ 2. CLARITY │
│ "critical" → what does it mean? │
│ "priority:critical" → clearly priority │
│ │
│ 3. AUTOCOMPLETE │
│ Type "area:" → see all area options │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NAMING RULES: │
│ │
│ ✅ DO: │
│ • Lowercase only (type:bug not Type:Bug) │
│ • Hyphens for spaces (good-first-issue) │
│ • Short but clear │
│ • Consistent prefix per category │
│ │
│ ❌ DON'T: │
│ • Mixed case (Frontend vs frontend) │
│ • Abbreviations without context (fe, be) │
│ • Same meaning different names (bug vs defect) │
│ • Overly long (type:user-reported-production-bug) │
└─────────────────────────────────────────────────────────────┘
Label Colors
Color Strategy
MEANINGFUL LABEL COLORS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ USE COLORS TO CONVEY MEANING: │
│ │
│ TYPE LABELS: │
│ [🔴 bug ] Red catches attention for issues │
│ [🟢 feature ] Green for new positive additions │
│ [🔵 improvement] Blue for enhancements │
│ [⚪ docs ] Gray for low-impact documentation │
│ │
│ STATUS LABELS: │
│ [🔴 blocked ] Red = problem needing attention │
│ [🟡 needs-review] Yellow = waiting, needs action │
│ [🟠 urgent ] Orange = high priority │
│ │
│ AREA LABELS: │
│ [🟣 frontend ] Purple for one team │
│ [🟤 backend ] Brown for another team │
│ All same category = similar color family │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PRINCIPLES: │
│ │
│ • Red = needs attention / problem │
│ • Yellow/Orange = caution / waiting │
│ • Green = positive / approved │
│ • Blue = informational │
│ • Gray = low priority / meta │
│ │
│ • Same category = similar hues │
│ • Limit bright colors (avoid noise) │
│ • Consider color blindness │
└─────────────────────────────────────────────────────────────┘
Label Governance
Who Creates Labels
LABEL MANAGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROBLEM WITH NO GOVERNANCE: │
│ │
│ Week 1: bug, feature, improvement │
│ Week 4: bug, Bug, BUG, defect, issue │
│ Week 8: 47 labels, half synonyms │
│ Week 12: Nobody uses labels anymore │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SOLUTION: LIMITED CREATION │
│ │
│ WHO CAN CREATE LABELS: │
│ ☑ Project managers / leads │
│ ☐ All team members │
│ │
│ PROCESS FOR NEW LABEL: │
│ 1. Anyone can suggest (Slack or retro) │
│ 2. Lead evaluates need │
│ 3. Check if existing label works │
│ 4. Create with proper naming/color │
│ 5. Announce to team │
│ │
│ QUARTERLY AUDIT: │
│ • Review all labels │
│ • Remove unused (< 5 uses in 90 days) │
│ • Merge duplicates │
│ • Update naming for consistency │
│ │
│ DOCUMENTED TAXONOMY: │
│ Keep a wiki page with: │
│ • All labels and their meanings │
│ • When to use each │
│ • Who can add new ones │
└─────────────────────────────────────────────────────────────┘
Label Audit
QUARTERLY LABEL CLEANUP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LABEL AUDIT CHECKLIST: │
│ │
│ STEP 1: USAGE REPORT │
│ │
│ Label Uses (90d) Last Used │
│ ────────────────────────────────────────────── │
│ type:bug 234 today │
│ type:feature 189 today │
│ area:frontend 156 today │
│ legacy-system 3 2 months ago ⚠️ │
│ temp-fix 1 3 months ago ⚠️ │
│ │
│ STEP 2: IDENTIFY PROBLEMS │
│ │
│ DUPLICATES: │
│ bug + defect + issue → consolidate to "type:bug" │
│ │
│ UNUSED: │
│ "legacy-system" (3 uses) → delete or rename │
│ │
│ UNCLEAR: │
│ "misc" → what does this mean? Remove. │
│ │
│ STEP 3: TAKE ACTION │
│ │
│ ☐ Delete unused labels (< 5 uses) │
│ ☐ Merge duplicates (update existing tasks) │
│ ☐ Rename for consistency (old → new) │
│ ☐ Document any new labels │
│ ☐ Announce changes to team │
│ │
│ BEFORE DELETING: │
│ Check if label is on any open tasks │
│ Replace with correct label first │
└─────────────────────────────────────────────────────────────┘
Using Labels for Workflow
Filtering with Labels
PRACTICAL LABEL FILTERING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMMON FILTER COMBINATIONS: │
│ │
│ "All frontend bugs": │
│ type:bug + area:frontend │
│ │
│ "Blocked items needing attention": │
│ status:blocked │
│ │
│ "Quick wins I can do now": │
│ effort:quick-win + NOT status:blocked │
│ │
│ "Items needing my review": │
│ status:needs-review + assigned to me │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SAVED FILTERS IN GITSCRUM: │
│ │
│ ⭐ My Frontend Work │
│ area:frontend + assigned to me │
│ │
│ ⭐ Bugs to Triage │
│ type:bug + status:new + no assignee │
│ │
│ ⭐ Ready for Review │
│ status:needs-review │
│ │
│ ⭐ Quick Wins Available │
│ effort:quick-win + status:open │
│ │
│ CREATE VIEWS BASED ON LABELS: │
│ Labels + saved filters = custom workflows │
└─────────────────────────────────────────────────────────────┘