YouTrack - Tags & Zeiterfassung

Dieser Leitfaden definiert standardisierte Tags und Arbeitstypen für alle YouTrack-Projekte bei ITeas, um eine einheitliche Klassifizierung um bessere Übersicht über Tickets zu gewährleisten.

---

Warum einheitliche Tags und Zeiterfassung?

Standardisierte Tags und Arbeitstypen über alle Projekte hinweg:

• Ermöglichen projektübergreifende Suchen und Filterung
• Erleichtern Reporting und Analytics
• Verbessern die Team-Zusammenarbeit
• Schaffen Klarheit bei der Ticket-Kategorisierung
• Verhindern Tag-Wildwuchs und Duplikate
• Ermöglichen genaue Projekt-Controlling und Abrechnungen

---

TAG-SYSTEM - Übersicht

1. Plattform-Tags

Definieren die technische Plattform oder Schicht, auf der das Ticket basiert.

Tag	Beschreibung	Verwendung
Web	Web-App spezifisch	Browser-basierte Anwendungsteile, Web-UI, Web-APIs
Backend	Backend	Business Logik
Frontend	Frontend	(Web) UI Themen
Android	Android-App-spezifisch	Mobile App-Entwicklung, Android-spezifische Features
API	REST-API oder externe Schnittstellen	API-Endpunkte, API-Integrationen, API-Dokumentation
CLI	Kommandozeilen-Tools	Console Commands, CLI-Utilities
CI/CD	CI/CD Pipeline	Gitlab, Foreman, Deployments

Empfehlung: Jedes Ticket sollte mindestens einen Plattform-Tag haben.

2. Typ-Tags

Klassifizieren die Art des Tickets.

Tag	Beschreibung	Verwendung
Bug	Fehler oder Defekt	Etwas funktioniert nicht wie erwartet
Feature Request	Neue Funktionalität	Komplett neue Features oder größere Erweiterungen
Dokumentation	Dokumentations-Arbeit	Docs schreiben/aktualisieren, Code-Kommentare
Maintenance	Wartungsarbeiten	Dependency-Updates, System-Wartung
Task	Arbeitspaket ohne Feature/Bug	Refactoring, Code-Cleanup, technische Schulden
Investigation	Recherche Arbeiten	Nachforschung und Recherchearbeiten für Umsetzung und Fehlerbehebung

Empfehlung: Jedes Ticket muss genau einen Typ-Tag haben.

---

Beispiel: Gut getaggtes Ticket

Titel: [MailManager] Bulk-Import für E-Mail-Domains hinzufügen

Tags:

• Feature Request (Typ)
• Web (Plattform)
• API (zusätzliche Plattform)

Warum gut: Klar erkennbar was (Feature Request), wo (Web/API), und in welchem Modul (mailManager im Titel).

---

BEST PRACTICES

Best Practices für Tag-Vergabe

Pflicht-Tags (Minimum)

Jedes Ticket sollte mindestens haben:

1. Ein Typ-Tag: Bug, Feature Request, Task, etc.
2. Ein Plattform-Tag: Web, Android, API, CLI, CI/CD

Richtwert für Tag-Anzahl

• Minimum: 1 Typ-Tag + 1 Plattform-Tag (2 Tags)
• Optimal: 2-4 Tags
• Maximum: Nicht mehr als 6 Tags (sonst wird es unübersichtlich)

Modulübergreifende Tickets

Verwenden Sie mehrere Plattform-Tags oder beschreiben Sie die betroffenen Module im Ticket-Titel:

Tags: Feature Request, Web, API
Titel: [mailManager][webhook] E-Mail-Benachrichtigungen für Webhook-Events

---

Best Practices für Tag-Namenskonventionen

Um Konsistenz zu gewährleisten:

1. Typ- und Plattform-Tags: Verwenden Sie die exakten Bezeichnungen aus den Tabellen oben
   • Beispiele: Feature Request, Web, API
2. Englisch: Tags in Englisch für internationale Konsistenz
3. Keine Abkürzungen: Ausgeschriebene Namen bevorzugen (außer etablierte wie API, CLI, CI/CD)
4. Module im Titel: Module nicht als Tag, sondern im Ticket-Titel angeben: [mailManager], [picking], [ytSync]
5. Konsistente Schreibweise: Exakt wie in der offiziellen Tag-Liste - Groß-/Kleinschreibung beachten

---

Best Practices für Tag-Verwaltung in YouTrack

Tags erstellen

Tags können in YouTrack auf zwei Arten erstellt werden:

1. Projekt-Ebene: In Projekt-Einstellungen → Tags
2. Global: In Admin → Tags (empfohlen für projektübergreifende Tags)

Empfehlung: Globale Tags

Erstellen Sie die Standard-Tags global, damit sie in allen Projekten verfügbar sind:

1. Admin → Tags
2. Neuen Tag erstellen
3. Optional: Beschreibung und Farbe hinzufügen
4. In allen Projekten aktivieren

Wer ist verantwortlich für Tag-Pflege?

• Ticket-Ersteller: Initiale Tags setzen
• Triage/Lead: Tags bei Review prüfen und korrigieren
• Alle: Tags können jederzeit aktualisiert werden, wenn sich Kontext ändert

---

HÄUFIG GESTELLTE FRAGEN (FAQ)

Kann ein Ticket mehrere Typ-Tags haben?

Nein. Ein Ticket sollte nur einen primären Typ haben (Bug ODER Feature Request ODER Task). Wenn es wirklich beides ist, entscheiden Sie sich für den Hauptaspekt.

Wann verwende ich Task vs Feature Request?

• Feature Request: Komplett neue Funktionalität für Endnutzer oder größere funktionale Erweiterung
• Task: Technische Arbeiten ohne direkte neue Funktionalität (Refactoring, Code-Cleanup, technische Schulden)

Beispiel:

• Feature Request: "Bulk-Import für Domains hinzufügen" (neue Nutzerfunktion)
• Task: "API-Client für bessere Wartbarkeit refactorn" (interne Verbesserung)

Was mache ich bei modulübergreifenden Tickets?

Verwenden Sie mehrere Plattform-Tags oder beschreiben Sie die betroffenen Module im Ticket-Titel:

Tags: Feature Request, Web, API
Titel: [mailManager][webhook] E-Mail-Benachrichtigungen für Webhook-Events

Bei framework-weiten Änderungen verwenden Sie aussagekräftige Titel wie "[Core]" oder "[Framework]".

Wie viele Tags sind zu viele?

Richtwert: 3-6 Tags pro Ticket

• Minimum: 1 Typ-Tag + 1 Plattform-Tag (2 Tags)
• Optimal: 2-4 Tags
• Maximum: Nicht mehr als 6 Tags (sonst wird es unübersichtlich)

SIEHE AUCH

• Ticket-Erstellungsrichtlinien
• Ticket-Vorlagen
• YouTrack Documentation
• YouTrack Zeiterfasssung