Skip to main content

Etichetta per issue e PR

Il repo non ha bisogno di un processo elaborato. Ha bisogno di un processo leggibile.

Issue

I buoni issue sono specifici a tal punto che un altro contributore può agire su di essi senza doverne indovinare la formulazione del problema. Includi:
  • quale comportamento è sbagliato o mancante
  • dove si manifesta
  • se è comportamento attuale oppure deriva della documentazione rispetto allo stato target
  • passaggi di riproduzione, quando rilevanti
  • screenshot o esempi di payload, quando aiutano concretamente
Evita:
  • richieste vaghe del tipo “migliora X”
  • combinare diversi bug non correlati in un unico issue
  • segnalare idee sullo stato target come se fossero regressioni

Pull request

Le buone pull request rendono la revisione economica. Includi:
  • un breve riassunto di cosa è cambiato
  • perché la modifica è necessaria
  • test aggiunti o interessati
  • documentazione aggiornata
  • gap noti o lavoro di follow-up

Etichetta di revisione

  • mantieni i commenti di revisione concreti e tecnici
  • metti in discussione le assunzioni, non le persone
  • segnala precocemente la deriva del comportamento e la documentazione mancante
  • preferisci riferimenti esatti a file/percorso rispetto ad affermazioni generiche
  • se una modifica amplia l’ambito a metà del lavoro, dividila

Aspettative per i maintainer

  • chiudi il ciclo sul feedback di revisione
  • segna esplicitamente il lavoro di follow-up invece di nasconderlo
  • non fare merge di lavoro che cambia il comportamento con check rossi
  • mantieni la documentazione allineata allo stato attuale del repo

Leggi anche