Scrivere le note di rilascio dalle pull request senza pubblicare dettagli interni superflui
Chiedi a Beeuni di leggere un repository GitHub collegato, verificare l’intervallo della release e preparare una bozza di note per gli utenti, con riferimenti alle modifiche.
Una pull request intitolata «Refactor export job» indica a chi la revisiona dove guardare, ma dice ben poco ai clienti. Le note di rilascio devono spiegare cosa è cambiato nel prodotto, chi ne è interessato e se la modifica è inclusa in questa release.
Verificare cosa è effettivamente incluso nella release
Consenti all’agente di accedere al repository tramite la connessione GitHub configurata. Chiedigli di individuare i tag precedente e attuale, confrontarne i commit ed esaminare le pull request associate. Se sono in corso più release, specifica il repository e i tag.
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.Una PR unita non è necessariamente stata distribuita, e una modifica unita nella stessa settimana potrebbe appartenere a una release successiva. Il confronto tra i tag stabilisce quale codice è incluso. Potrebbe comunque essere necessario verificare con il team i flag delle funzionalità e lo stato del rollout.
Chiedi all’agente di preparare un elenco di lavoro riservato con la PR di origine, il comportamento modificato, gli utenti interessati e la presenza della modifica nella release. Controlla le modifiche annullate e le funzionalità ancora disattivate. Lascia le voci incerte fuori dalla bozza pubblica finché qualcuno non le conferma.
Dai dettagli di implementazione alle modifiche per gli utenti
Questi esempi illustrativi di note per le PR mostrano alcune scelte editoriali comuni:
| Nota di lavoro | Bozza delle note di rilascio | Scelta editoriale |
|---|---|---|
| Salvare i filtri selezionati nei parametri della query | Le viste filtrate mantengono i filtri quando condividi il link. | Descrivere il comportamento visibile |
| Correggere l’invio duplicato con un doppio clic | Corretto un problema per cui fare clic due volte su Invia poteva creare richieste duplicate. | Indicare la causa e l’effetto |
| Riorganizzare gli helper dei test | Escludere dalle note pubbliche | Mantenere le attività di manutenzione nel registro interno |
| Aggiungere l’esportazione dietro un flag di funzionalità disattivato | Attendere che l’esportazione sia disponibile | Verificare la disponibilità prima di annunciarla |
Organizzare le informazioni in base a ciò che interessa ai lettori
Quando serve, usa sezioni come Nuove funzionalità, Miglioramenti e Correzioni. Evita le intestazioni vuote. Riunisci in un’unica voce le PR che contribuiscono alla stessa funzionalità. Tieni separate le correzioni distinte quando riguardano azioni diverse.
Non nascondere azioni necessarie in un elenco generico di miglioramenti. Se cambia un campo API, indica la forma precedente e quella nuova e inserisci un link alle istruzioni per la migrazione. Se il comportamento cambia solo per determinati account o client, specifica chi ne è interessato. Chiedi al responsabile della funzionalità di confermare questi dettagli.
Mantenere la bozza collegata alle prove
- Conserva i riferimenti alle PR o ai commit nella copia di revisione, anche se vengono rimossi dalle note pubbliche.
- Verifica che ogni funzionalità annunciata sia disponibile nella release descritta.
- Rimuovi nomi host interni, credenziali, dati dei clienti e contenuti di issue non pubblicate.
- Sostituisci affermazioni come «più veloce» con una descrizione precisa del comportamento, a meno che tu non possa citare una misurazione.
Chiedi due file: la bozza pubblica e l’elenco di lavoro con le voci incluse, escluse e ancora da chiarire. Dopo la revisione, puoi chiedere all’agente di aggiornare la bozza nel repository, se la connessione consente la scrittura. La pubblicazione della release richiede un’istruzione separata. Se le note dicono che è stato corretto un problema con un modulo, la guida ai test del sito web descrive il resoconto di riproduzione che puoi usare per verificare l’affermazione.
Altri articoli
Infrastruttura per la ricerca sull’RSI: esecuzione e valutazione di agenti che si auto-migliorano
Come Beeuni aiuta a ripetere esperimenti di miglioramento degli agenti: modificare codice e istruzioni, eseguire test, analizzare errori e confrontare versioni.
Usa Beeuni per eseguire e valutare un esperimento di fine-tuning di un modello
Affida a un agente la preparazione dei dati di addestramento, l’avvio di un job di fine-tuning sul computer di addestramento connesso, l’analisi degli errori e il confronto tra gli output del modello.