diff --git a/Issue-Guide.md b/Issue-Guide.md new file mode 100644 index 0000000..5efa02f --- /dev/null +++ b/Issue-Guide.md @@ -0,0 +1,86 @@ +# 📖 EZ-Games Issue Guide + +Willkommen im Issue Guide! Hier dokumentieren und verwalten wir alle Aufgaben, Bugs und Features für unsere Projekte (wie *Happy Forest*). Diese Seite erklärt, wie wir Issues in Forgejo strukturieren, um effizient im Team zu arbeiten. + +--- + +## 🏷️ 1. Labels & Kategorien + +Wir nutzen ein strukturiertes Label-System. Die meisten unserer Label-Kategorien (Scopes) sind **exklusiv** (mit dem Haken *Exclusive*) eingestellt. Das bedeutet, dass sich Labels derselben Kategorie gegenseitig ausschließen (ein Issue kann z. B. nicht gleichzeitig `Typ/Bug` und `Typ/Feature` oder `Asset/2D` und `Asset/3D` sein). + +### 🎨 Assets (Exklusiv) +* `Asset/2D` | `Asset/3D` | `Asset/Animation` | `Asset/Sound` | `Asset/UI` + +### 💻 Code & Technik (Exklusiv) +* `Code/Gameplay` | `Code/Network` | `Code/Shader` | `Code/UI` + +### 🎲 Gamedesign (Exklusiv) +* `Design/Balance` | `Design/Game` | `Design/Level` + +### 📌 Typ (Ticket-Typ) (Exklusiv) +* `Typ/Bug`: Fehler im Spiel oder System +* `Typ/Feature`: Ein neues, größeres Feature +* `Typ/Enhancement`: Verbesserung eines bestehenden Features +* `Typ/Documentation`: Aufgaben rund um Wiki und Dokumentation + +### 🚦 Priorität & Status (Exklusiv) +* **Priority:** `Priority/Critical` | `Priority/High` | `Priority/Medium` | `Priority/Low` +* **Status:** `Status/Blocked` (Wartet auf andere Aufgaben) | `Status/Need More Info` (Details fehlen) + +### ✅ Approvals (Freigaben) +* `Approval/RZ-Approved`, `Approval/DZ-Approved`, `Approval/SM-Approved` +*(Werden vergeben, wenn Teammitglieder ein Konzept oder Asset absegnen. Diese sind **nicht** exklusiv, damit mehrere Personen parallel freigeben können).* + +--- + +## 📝 2. Issues richtig anlegen + +Ein gutes Issue ist klar formuliert und enthält alle wichtigen Infos für den Bearbeiter. + +* **Zuweisung (Assignees):** Weise das Issue rechts in der Seitenleiste der Person zu, die die Aufgabe bearbeiten soll. +* **Markierungen:** Mit `@Username` (z. B. `@Pixel`) kannst du Teammitglieder direkt erwähnen. Sie erhalten dann eine Benachrichtigung. +* **Bilder & Code:** Nutze Drag & Drop für Screenshots oder kleine Gameplay-Clips. Code-Schnipsel packst du in drei Backticks (\`\`\`). + +### 📋 To-Do-Listen (WICHTIG!) +Wenn eine Aufgabe aus mehreren Teilschritten besteht, nutze eine Markdown-Checkliste: + +```markdown +- [ ] Grundrisse planen +- [ ] 3D-Blockout erstellen +- [x] Texturen zuweisen (bereits erledigt) +``` + +**Achtung:** Damit Forgejo oben im Ticket einen Fortschrittsbalken (z. B. *1 von 3 erledigt*) anzeigt, **muss** diese Liste im allerersten Beitrag (der Hauptbeschreibung) des Issues stehen, nicht in den Kommentaren! + +--- + +## 📊 3. Das Kanban-Board (Projects) + +Wir nutzen das Kanban-Board, um den Fortschritt aller Aufgaben visuell zu tracken. + +1. Gehe in der rechten Seitenleiste eines offenen Issues auf das **Zahnrad neben "Projects"**. +2. Wähle das **Main Board** (oder das aktuelle Sprint-Board) aus. +3. Das Issue landet nun als Karte auf dem Board (standardmäßig in der ganz linken Spalte, z. B. *Backlog* oder *To Do*). +4. Unter dem Reiter **Projects** (oben im Menü) kannst du die Karten per Drag & Drop in Spalten wie *In Progress* oder *Done* verschieben. + +--- + +## 🤖 4. Workflows & Git-Automatisierung + +Forgejo ist eng mit unserem Code-Repository verzahnt. Du kannst Issues automatisch direkt aus deinen Git-Commits heraus steuern! + +* **Tickets automatisch schließen:** + Wenn du Code in GitHub Desktop/Git committest, der ein Issue löst, schreibe in die Commit-Nachricht: + `Fixes #12` oder `Closes #12` (wobei 12 die Issue-Nummer ist). + Sobald du pushst, schließt Forgejo das Issue automatisch und entfernt es von der aktiven Ansicht des Kanban-Boards. +* **Tickets referenzieren:** + Schreibe in einem Kommentar einfach `#12`, um einen klickbaren Link zum entsprechenden Ticket zu erzeugen. + +--- + +## ⏱️ 5. Zeiterfassung (Time Tracking) + +Um am Ende zu sehen, wie viel Aufwand in ein Projekt geflossen ist, nutzen wir die integrierte Zeiterfassung. Schreibe dazu einfach diese Befehle in einen neuen Kommentar im Issue: + +* `/estimated 4h 30m` – Setzt die **geschätzte** Dauer der Aufgabe auf 4,5 Stunden. +* `/spend 1h 15m` – Bucht 1 Stunde und 15 Minuten **gearbeitete** Zeit auf das Ticket. \ No newline at end of file