Naming conventions that scale
One good label is luck. A hundred consistent labels is a convention — a small set of rules the whole team follows without thinking. This guide covers the rules that actually survive contact with real teams, drawn from widely used naming practices in software, IT and operations.
Rule 1: one pattern, everywhere
The single most important rule: pick one label pattern and use it across every tool. The pattern [TEAM]-[Project]-[Descriptor] (for example, MKTG-Website-Relaunch) works because each segment answers one question: who owns it, what it is, which one.
Write the pattern down in a one-page doc. Conventions that live only in someone's head are not conventions.
Rule 2: prefixes carry the metadata
Short fixed prefixes at the start of a label act like filing cabinets. Common schemes:
| Prefix style | Example | Best for |
|---|---|---|
| Team prefix | ENG-, MKTG-, OPS- | Ownership at a glance |
| Type prefix | PRJ-, EXP- (experiment), TMP- | Lifecycle and purpose |
| Client prefix | ACME-, GLOBEX- | Agency and freelance work |
| Status suffix | -ACTIVE, -ARCHIVE, -DRAFT | Retired vs live projects |
Keep prefixes short (a dozen characters max) and consistent — PRJ everywhere, never Proj in one tool and project in another.
Rule 3: one casing, one separator
For machine-readable labels (file names, slugs, repo names, branch names), choose one case style and one separator:
- kebab-case (website-redesign) — the most portable; safe in URLs, file systems and most tools.
- snake_case (website_redesign) — common in code and data pipelines.
- PascalCase (WebsiteRedesign) — good for tags and display labels.
Avoid spaces and special characters (# % & / \ ? * : < > |) in machine labels — they break URLs, complicate search and cause sync errors. Spaces are fine in human display names.
Rule 4: dates in YYYY-MM-DD
Any recurring project needs a date, and dates must sort. 2026-10 sorts; "Oct 2026" and "10-2026" do not sort the same way. Use YYYY-MM-DD for specific dates and YYYY-MM for months. Never use ambiguous formats like 10-11-2026.
Rule 5: guarantee uniqueness
Two projects with the same label is a data-corruption event waiting to happen. Uniqueness strategies, from simplest to strongest:
- Running numbers: PRJ-001, PRJ-002… — simple, sortable, needs a shared counter.
- Year + descriptor: Website-Redesign-2026 — unique unless the project repeats yearly (then add the month).
- Client/team + descriptor: ACME-Website — unique within that client's portfolio.
- Combine: PRJ-2026-042 — belt and suspenders for large orgs.
The five convention killers
- Synonym drift: "Website", "Site" and "Web" for the same thing. Pick one term per concept and stick to it.
- Mixed granularity: "Marketing" next to "Q3-Email-Subject-Test-7" in the same list. Keep one level of specificity per label layer.
- Overdescriptive labels: "Website-Redesign-Project-For-The-Marketing-Team-Q3" is a sentence, not a label. Details go in the description field.
- Trend-chasing words: "Synergy", "Growth-Hack", "AI-Powered" age badly. Name what it is, not what is fashionable.
- Silent exceptions: every "just this once" breaks the system for everyone searching later. If the rule does not fit, change the rule — do not break it quietly.
Rolling it out to a team
- Draft the one-pager: pattern, prefixes, casing, date format, examples. One page, not ten.
- Fix the old mess once: rename the worst offenders; archive or alias the rest. A convention adopted only for new projects still leaves the old chaos searchable.
- Put examples where labels are born: the new-project template in your tracker, the repo README, the shared drive's top-level folder.
- Review quarterly: conventions rot as teams change. A 15-minute review every few months keeps the system honest.
Generate first, systematize second: use the LabelLab generator to produce candidate labels in your chosen style, then lock the winners into your convention doc.