Release Notes aus Pull Requests erstellen, ohne interne Details zu veröffentlichen

Ein Pull Request mit dem Titel „Exportauftrag refaktorieren“ zeigt einem Reviewer, wo er nachsehen muss. Für Kunden sagt er kaum etwas aus. Release Notes sollten erklären, was sich am Produkt geändert hat, wen es betrifft und ob die Änderung in diesem Release verfügbar ist.

Ermitteln, was tatsächlich im Release enthalten ist

Geben Sie dem Agenten über Ihre konfigurierte GitHub-Verbindung Zugriff auf das Repository. Bitten Sie ihn, das vorherige und das aktuelle Tag zu finden, die zugehörigen Commits zu vergleichen und die entsprechenden Pull Requests zu prüfen. Geben Sie Repository und Tags selbst an, wenn mehrere Releases gleichzeitig vorbereitet werden.

Read the connected repository and compare v1.4.0 with v1.5.0.
Draft release notes for users, grouped into features and fixes.
Inspect the linked PRs and diffs rather than relying on titles alone.
Keep a separate list of internal changes, reversions, and uncertain availability.
Save the draft with PR references. Do not publish a release.

Ein gemergter PR ist nicht unbedingt auch ausgerollt, und eine Änderung, die in derselben Woche gemergt wurde, kann zu einem späteren Release gehören. Der Tag-Vergleich zeigt, welcher Code enthalten ist. Feature-Flags und der Rollout-Status müssen möglicherweise weiterhin vom Team bestätigt werden.

Bitten Sie den Agenten, eine private Arbeitsliste mit Quell-PR, geändertem Verhalten, betroffenen Nutzern und der Frage zu erstellen, ob die Änderung im Release enthalten ist. Prüfen Sie zurückgenommene Änderungen und Funktionen, die weiterhin deaktiviert sind. Lassen Sie unklare Einträge aus dem öffentlichen Entwurf heraus, bis jemand sie bestätigt hat.

Von Implementierungsdetails zu Änderungen für Nutzer

Diese beispielhaften PR-Notizen veranschaulichen einige typische redaktionelle Entscheidungen:

Nach den Bedürfnissen der Leser gruppieren

Verwenden Sie Abschnitte wie „Neue Funktionen“, „Verbesserungen“ und „Fehlerbehebungen“, wenn das Release sie erfordert. Lassen Sie leere Überschriften weg. Fassen Sie mehrere PRs, die gemeinsam eine Funktion bereitstellen, zu einem Eintrag zusammen. Führen Sie unterschiedliche Fehlerbehebungen getrennt auf, wenn sie verschiedene Aktionen betreffen.

Verstecken Sie erforderliche Schritte nicht in einer allgemeinen Liste mit Verbesserungen. Ändert sich ein API-Feld, nennen Sie die alte und die neue Form und verlinken Sie auf eine Anleitung zur Migration. Ändert sich das Verhalten nur bei bestimmten Konten oder Clients, geben Sie an, für wen die Änderung gilt. Lassen Sie diese Angaben vom zuständigen Feature-Verantwortlichen bestätigen.

Den Entwurf mit seinen Belegen verknüpft halten

• Lassen Sie PR- oder Commit-Verweise in der Review-Fassung stehen, auch wenn sie aus den öffentlichen Notes entfernt werden.
• Prüfen Sie, ob jede angekündigte Funktion im beschriebenen Release verfügbar ist.
• Entfernen Sie interne Hostnamen, Zugangsdaten, Kundendetails und Inhalte unveröffentlichter Issues.
• Ersetzen Sie Aussagen wie „schneller“ durch eine genaue Beschreibung des Verhaltens, sofern Sie keine Messwerte anführen können.

Bitten Sie um zwei Dateien: den öffentlichen Entwurf und die Arbeitsliste mit enthaltenen, ausgeschlossenen und noch ungeklärten Einträgen. Nach der Prüfung können Sie den Agenten bitten, den Entwurf im Repository zu aktualisieren, sofern die Verbindung Schreibzugriff erlaubt. Die Veröffentlichung des Releases ist ein separater Auftrag. Wenn in den Notes steht, dass ein Formularfehler behoben wurde, beschreibt der Leitfaden zum Website-Testen das Reproduktionsprotokoll, mit dem Sie diese Aussage überprüfen können.