126 lines
2.2 KiB
Markdown
126 lines
2.2 KiB
Markdown
# 🤝 Contribuer à Veza
|
||
|
||
Merci de contribuer à Veza !
|
||
Ce guide formalise un workflow clair, reproductible et adapté à la complexité du projet.
|
||
|
||
---
|
||
|
||
# 1. Philosophie du projet
|
||
|
||
Veza suit trois principes :
|
||
|
||
1. **Cohérence** — respecter la structure ORIGIN (docs/ORIGIN/).
|
||
2. **Lisibilité** — code clair, typé, testé, documenté.
|
||
3. **Évolutivité** — préférer une architecture modulaire à un hack rapide.
|
||
|
||
---
|
||
|
||
# 2. Branching Model
|
||
|
||
- `main` : toujours stable, toujours déployable.
|
||
- `develop` (optionnel) : branche d’intégration continue.
|
||
- Branches par fonctionnalité :
|
||
|
||
````
|
||
|
||
feat/<nom-fonction>
|
||
fix/<bug>
|
||
chore/<tâche-technique>
|
||
refactor/<refacto>
|
||
docs/<documentation>
|
||
|
||
```
|
||
|
||
Exemples :
|
||
|
||
- `feat/auth-refresh-tokens`
|
||
- `fix/jwt-uuid-mismatch`
|
||
- `refactor/chat-room-architecture`
|
||
|
||
---
|
||
|
||
# 3. Convention de commits
|
||
|
||
Suivre le style **Conventional Commits** :
|
||
|
||
```
|
||
|
||
feat: ajout fonctionnalité
|
||
fix: correction de bug
|
||
chore: tâches automatiques, maj deps
|
||
docs: ajout ou mise à jour docs
|
||
refactor: restructuration sans changement de comportement
|
||
test: ajout/màj tests
|
||
ci: pipeline CI/CD
|
||
|
||
````
|
||
|
||
Exemples :
|
||
|
||
- `feat: add adaptive HLS transcoding worker`
|
||
- `fix: correct JWT user_id mismatch between Go and Rust`
|
||
- `refactor: isolate DM module in chat-server`
|
||
|
||
---
|
||
|
||
# 4. Tests & Qualité
|
||
|
||
Avant toute PR :
|
||
|
||
1. Lancer les tests Go :
|
||
```bash
|
||
go test ./...
|
||
````
|
||
|
||
2. Lancer les tests Rust :
|
||
|
||
```bash
|
||
cargo test
|
||
```
|
||
|
||
3. Lancer les tests du frontend :
|
||
|
||
```bash
|
||
pnpm test
|
||
```
|
||
|
||
4. Vérifier lfmt / clippy :
|
||
|
||
```bash
|
||
cargo fmt --all --check
|
||
cargo clippy -- -D warnings
|
||
```
|
||
|
||
5. Vérifier go vet :
|
||
|
||
```bash
|
||
go vet ./...
|
||
```
|
||
|
||
---
|
||
|
||
# 5. Pull Requests
|
||
|
||
1. Toujours ouvrir une PR, même si vous êtes seul.
|
||
2. Décrire :
|
||
|
||
* Contexte
|
||
* Changement
|
||
* Impact sur l'architecture ORIGIN
|
||
* Migrations nécessaires ?
|
||
* Compatibilité ascendante ?
|
||
3. Ajouter des captures si c’est du frontend.
|
||
4. Pas de merge si CI échoue.
|
||
|
||
---
|
||
|
||
# 6. Documentation
|
||
|
||
* Tout changement significatif doit être reflété dans `docs/`.
|
||
* Si une décision touche à l’architecture : mettre à jour la section `ORIGIN`.
|
||
|
||
---
|
||
|
||
Merci de rendre Veza meilleur !
|
||
|
||
|