|
2 | 2 |
|
3 | 3 | Grazie per il tuo interesse nel contribuire a Visura API! Questo documento fornisce le linee guida per partecipare al progetto. |
4 | 4 |
|
| 5 | +> **Regola fondamentale**: prima di scrivere codice, **apri sempre una issue** per discutere la modifica. Le PR senza issue collegata e approvata non verranno revisionate. Questo vale per feature, refactoring e fix non banali. |
| 6 | +
|
| 7 | +## Tempi di risposta |
| 8 | + |
| 9 | +Questo progetto è mantenuto nel tempo libero. Ecco cosa aspettarsi: |
| 10 | + |
| 11 | +- **Issue**: risposta entro 7 giorni |
| 12 | +- **PR con issue approvata**: prima review entro 14 giorni |
| 13 | +- **PR senza issue**: chiusa con richiesta di aprire prima una issue |
| 14 | + |
| 15 | +Se non ricevi risposta entro questi tempi, sentiti libero di fare un ping gentile nel thread. |
| 16 | + |
5 | 17 | ## Codice di condotta |
6 | 18 |
|
7 | 19 | Partecipando a questo progetto accetti di rispettare il nostro [Codice di Condotta](CODE_OF_CONDUCT.md). |
8 | 20 |
|
| 21 | +## Policy sull'uso di strumenti AI |
| 22 | + |
| 23 | +L'uso di strumenti AI (GitHub Copilot, ChatGPT, Claude, ecc.) come **supporto** è benvenuto, ma con regole chiare: |
| 24 | + |
| 25 | +- **Dichiaralo**: nel template della PR c'è una sezione apposita. Sii trasparente su cosa è stato generato da AI. |
| 26 | +- **Comprendi il codice**: devi essere in grado di spiegare ogni riga della tua PR. Se il reviewer ti chiede "perché hai fatto X?" e la risposta è "l'ha scritto l'AI", la PR verrà rifiutata. |
| 27 | +- **Testa tutto**: il codice generato da AI deve essere testato localmente end-to-end, esattamente come il codice scritto a mano. |
| 28 | +- **No bulk PR**: le PR che riformattano massivamente il codice o aggiungono centinaia di righe non richieste non verranno revisionate. Mantieni le PR piccole e focalizzate. |
| 29 | + |
| 30 | +Le PR palesemente generate da AI senza comprensione del progetto (selettori sbagliati, flussi non testati, dipendenze inventate) verranno chiuse senza review. |
| 31 | + |
9 | 32 | ## Come segnalare un problema |
10 | 33 |
|
11 | 34 | 1. Controlla prima le [issue esistenti](https://github.com/zornade/visura-api/issues) per assicurarti che il problema non sia già stato segnalato |
12 | 35 | 2. Se è un problema di sicurezza, **NON** aprire una issue pubblica — segui le istruzioni in [SECURITY.md](SECURITY.md) |
13 | | -3. Apri una nuova issue usando il template appropriato, fornendo: |
14 | | - - Descrizione chiara del problema |
15 | | - - Passi per riprodurlo |
16 | | - - Comportamento atteso vs comportamento osservato |
17 | | - - Versione di Python e del sistema operativo |
18 | | - - Log pertinenti (rimuovi sempre le credenziali!) |
| 36 | +3. Apri una nuova issue usando il template appropriato (Bug Report o Feature Request) |
19 | 37 |
|
20 | 38 | ## Come proporre modifiche |
21 | 39 |
|
| 40 | +### Regola: Issue prima, PR dopo |
| 41 | + |
| 42 | +1. **Apri una issue** descrivendo cosa vuoi fare e perché |
| 43 | +2. **Attendi il via libera** del maintainer (etichetta `approved` o commento esplicito) |
| 44 | +3. **Solo dopo**, crea il fork e scrivi il codice |
| 45 | + |
| 46 | +Questo evita di sprecare il tuo tempo su modifiche che non verranno accettate e permette di allinearsi sull'architettura prima di scrivere codice. |
| 47 | + |
22 | 48 | ### Preparare l'ambiente di sviluppo |
23 | 49 |
|
24 | 50 | ```bash |
@@ -52,16 +78,28 @@ cp .env.example .env |
52 | 78 | ``` |
53 | 79 | 3. **Scrivi il codice** seguendo le convenzioni del progetto |
54 | 80 | 4. **Aggiungi test** per le modifiche, se applicabile |
55 | | -5. **Esegui i test** per verificare che nulla sia rotto: |
| 81 | +5. **Verifica linting e formattazione** prima del commit: |
| 82 | + ```bash |
| 83 | + black --check . |
| 84 | + ruff check . |
| 85 | + ``` |
| 86 | +6. **Esegui i test** per verificare che nulla sia rotto: |
56 | 87 | ```bash |
57 | 88 | python -m pytest test_*.py -v |
58 | 89 | ``` |
59 | | -6. **Fai commit** con messaggi chiari in italiano: |
| 90 | +7. **Fai rebase su main** prima di aprire la PR: |
| 91 | + ```bash |
| 92 | + git fetch upstream |
| 93 | + git rebase upstream/main |
| 94 | + ``` |
| 95 | +8. **Fai commit** con messaggi chiari in italiano: |
60 | 96 | ```bash |
61 | 97 | git commit -m "fix: corretto errore nella selezione della provincia" |
62 | 98 | git commit -m "feat: aggiunto supporto per ricerca per codice fiscale" |
63 | 99 | ``` |
64 | | -7. **Apri una Pull Request** verso il branch `main` |
| 100 | +9. **Apri una Pull Request** verso il branch `main`, compilando il template e collegando la issue |
| 101 | + |
| 102 | +> ⚡ La CI eseguirà automaticamente linting (ruff + black), test e un audit di sicurezza sulle dipendenze. Assicurati che passi tutto prima di chiedere la review. |
65 | 103 |
|
66 | 104 | ### Convenzioni per i messaggi di commit |
67 | 105 |
|
|
0 commit comments