Using Labels Effectively in GitScrum | Organization
Organize and filter work with labels in GitScrum. Create a taxonomy for types, areas, and status that adds clarity without label chaos.
8 min read
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 │
└─────────────────────────────────────────────────────────────┘