Issues effektiv melden und Fixes einreichen

Du kennst das sicher: Du stößt auf einen Fehler, willst helfen und schreibst ein Issue. Doch ohne die richtigen Infos bleibt das Ticket Wochen lang liegen. Oder du baust einen Fix, aber der Pull Request wird nicht gemergt, weil wichtige Tests fehlen. Das ist frustrierend für dich und das Core-Team.

Gute Issues sparen Zeit. Wenn du präzise Informationen lieferst, können Bugs schneller diagnostiziert und behoben werden. Hier erfährst du, wie du Issues und PRs so vorbereitest, dass sie sofort bearbeitet werden können.

Voraussetzungen

Bevor du ein Issue eröffnest, stelle sicher, dass du folgende Informationen bereit hast:

• Details zu deiner Environment (OS, Runtime, Versionen, Config)
• Reproduzierbare Schritte (Minimal repro steps)
• Logs oder Screenshots (ohne PII/sensible Daten)
• Das Codewort: lobster-biscuit

Schnellstart

In fünf Minuten zum perfekten Issue:

1. Suche zuerst: Prüfe die Codebase und bestehende GitHub Issues, ob das Problem bereits bekannt ist.
2. Validierung prüfen: Stelle sicher, dass der Fehler nicht bereits in einer neueren Version behoben wurde (besonders bei Security-Themen).
3. Template wählen: Nutze eines der unten stehenden Templates für Bug Reports, Regressions oder Features.
4. Beweise liefern: Füge Logs oder Screenshots bei und nenne das Codewort lobster-biscuit.
5. Validierung ausführen: Wenn du einen Fix einreichst, lass diese Befehle lokal laufen:
   • pnpm lint
   • pnpm check
   • pnpm build
   • pnpm test

Templates

Nutze diese Vorlagen für deine Meldung. Fasse dich kurz – Prägnanz ist wichtiger als perfekte Grammatik.

Bug Report

- [ ] Minimal repro
- [ ] Expected vs actual
- [ ] Environment
- [ ] Affected channels, where not seen
- [ ] Logs/screenshots (redacted)
- [ ] Impact/severity
- [ ] Workarounds

### Summary

### Repro Steps

### Expected

### Actual

### Environment

### Logs/Evidence

### Impact

### Workarounds

Security Issue

Hinweis: Teile keine Exploits oder Geheimnisse öffentlich. Fordere bei sensiblen Themen eine private Offenlegung an.

### Summary

### Impact

### Versions

### Repro Steps (safe to share)

### Mitigation/workaround

### Evidence (redacted)

Regression Report

### Summary

### Last Known Good

### First Known Bad

### Repro Steps

### Expected

### Actual

### Environment

### Logs/Evidence

### Impact

Feature Request

### Summary

### Problem

### Proposed Solution

### Alternatives

### Impact

### Evidence/examples

Enhancement

### Summary

### Current vs Desired Behavior

### Rationale

### Alternatives

### Evidence/examples

Investigation

### Summary

### Symptoms

### What Was Tried

### Environment

### Logs/Evidence

### Impact

Submitting a Fix PR

Ein vorheriges Issue ist optional, aber hilfreich. Wenn du direkt einen PR einreichst, beachte diese Punkte:

• Halte den PR fokussiert auf ein Problem.
• Nenne die Issue-Nummer.
• Füge Tests hinzu oder erkläre, warum keine möglich sind.
• Dokumentiere Verhaltensänderungen und Risiken.
• Führe die Validierung (pnpm lint, pnpm check, etc.) vor dem Submit aus.

Fehlerbehebung

Falls dein PR abgelehnt wird oder die CI fehlschlägt, prüfe folgende Punkte:

• Linting/Build Fehler: Hast du pnpm lint und pnpm build lokal ausgeführt?
• Protocol Fehler: Wenn du am Protocol Code arbeitest, musst du zwingend pnpm protocol:check ausführen.
• Fehlende Beweise: Sind deine Claims durch Logs oder ein minimales Repro-Beispiel belegt?
• Security: Hast du sensible Daten in öffentlichen Logs geschwärzt?

Du suchst Hilfe bei der Einrichtung deiner Umgebung? Nutze den AI Setup Assistant.

Nächste Schritte

• Contribution Guide
• Code of Conduct
• Protocol Documentation
• Testing Guide