186 lines
6.4 KiB
Markdown
186 lines
6.4 KiB
Markdown
|
# Guide de Contribution Talas
|
||
|
|
|
||
|
|
> Comment contribuer au projet Talas — code, documentation, design, hardware, traductions.
|
||
|
|
> Dernière mise à jour : 27 mars 2026.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Bienvenue
|
||
|
|
|
||
|
|
Talas est un projet ouvert. Les schémas hardware sont sous CERN-OHL-W 2.0, la documentation sous CC BY-SA 4.0. Le code de Veza est propriétaire. Toute contribution qui respecte les valeurs du projet est la bienvenue.
|
||
|
|
|
||
|
|
Avant de contribuer, prends le temps de lire :
|
||
|
|
- [[00_META/Manifeste/MANIFESTE_ETHIQUE_TALAS]] — Les engagements non-négociables
|
||
|
|
- [[00_META/CHARTE_OPEN_CORE]] — Ce qui est commons vs commercial
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Comment contribuer
|
||
|
|
|
||
|
|
### Code (Veza)
|
||
|
|
|
||
|
|
Le code source vit dans `/home/senke/git/talas/veza/` (monorepo).
|
||
|
|
|
||
|
|
| Composant | Langage | Répertoire |
|
||
|
|
|-----------|---------|-----------|
|
||
|
|
| Backend API | Go (Gin, GORM) | `veza-backend-api/` |
|
||
|
|
| Stream Server | Rust (Axum) | `veza-stream-server/` |
|
||
|
|
| Frontend | React 18, TypeScript, Tailwind | `apps/web/` |
|
||
|
|
| Desktop | Electron (wrapper) | `veza-desktop/` |
|
||
|
|
|
||
|
|
**Pour commencer :**
|
||
|
|
1. Lire [[03_APPS_&_SERVICES/ARCHITECTURE_VEZA]] pour comprendre l'architecture
|
||
|
|
2. Suivre le setup développeur dans [[04_INFRA_DEPLOIEMENT/CI_CD/PROCEDURES_DEPLOIEMENT]] §2
|
||
|
|
3. Consulter les issues ouvertes sur Gitea/Forgejo
|
||
|
|
|
||
|
|
### Documentation (ce knowledge base)
|
||
|
|
|
||
|
|
Ce dépôt (`TG__Talas_Group/`) est un graphe Logseq de ~80 fichiers markdown.
|
||
|
|
|
||
|
|
**Conventions :**
|
||
|
|
- Tout en **français**
|
||
|
|
- Utiliser `[[wikilinks]]` pour les références croisées (Logseq les résout)
|
||
|
|
- Noms de fichiers principaux en MAJUSCULES (ex: `ARCHITECTURE_VEZA.md`)
|
||
|
|
- Sous-dossiers pour les fichiers détaillés
|
||
|
|
- Pas de fichiers dans `13_ARCHIVES/` (historique figé)
|
||
|
|
- Pas de fichiers de code ici (le code est dans le repo Veza)
|
||
|
|
|
||
|
|
### Design et UX
|
||
|
|
|
||
|
|
- Système de design : Sumi V3 (voir [[05_EXPERIENCE_UTILISATEUR/SUMI_V3_SPECIFICATION]])
|
||
|
|
- Outil : Penpot (self-hosted)
|
||
|
|
- Direction artistique : [[05_EXPERIENCE_UTILISATEUR/DIRECTION_ARTISTIQUE_TALAS]]
|
||
|
|
|
||
|
|
### Traductions
|
||
|
|
|
||
|
|
Veza supporte 3 langues (EN/FR/ES) via i18next.
|
||
|
|
- Fichiers : `apps/web/src/locales/`
|
||
|
|
- Ajouter une langue : créer un dossier de locale, traduire les clés JSON
|
||
|
|
|
||
|
|
### Hardware
|
||
|
|
|
||
|
|
Les schémas du microphone sont ouverts sous CERN-OHL-W 2.0.
|
||
|
|
- Outil : KiCAD
|
||
|
|
- Fichiers : `02_PRODUITS_PHYSIQUES/Microphone/Conception/`
|
||
|
|
- BOM : `02_PRODUITS_PHYSIQUES/Microphone/BOM/`
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Prérequis techniques
|
||
|
|
|
||
|
|
### Pour le code Veza
|
||
|
|
|
||
|
|
| Outil | Version | Installation |
|
||
|
|
|-------|---------|-------------|
|
||
|
|
| Go | 1.24+ | [go.dev/dl](https://go.dev/dl/) |
|
||
|
|
| Rust + Cargo | Stable | [rustup.rs](https://rustup.rs/) |
|
||
|
|
| Node.js | 20+ | [nodejs.org](https://nodejs.org/) |
|
||
|
|
| Docker + Compose | 24+ | [docs.docker.com](https://docs.docker.com/) |
|
||
|
|
| Make | — | Fourni par le système |
|
||
|
|
|
||
|
|
### Pour la documentation
|
||
|
|
|
||
|
|
- Éditeur markdown (VS Code, Neovim, etc.)
|
||
|
|
- Optionnel : Logseq pour naviguer le graphe visuellement
|
||
|
|
|
||
|
|
### Pour le hardware
|
||
|
|
|
||
|
|
- KiCAD 8+ pour les schémas et PCB
|
||
|
|
- Multimètre et oscilloscope pour les tests (voir [[10_QUALITE_TESTS/Tests_Hardware/PROTOCOLES_TESTS_HARDWARE]])
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Process de contribution
|
||
|
|
|
||
|
|
### 1. Créer une branche
|
||
|
|
|
||
|
|
```bash
|
||
|
|
git checkout -b feat/description-courte # nouvelle fonctionnalité
|
||
|
|
git checkout -b fix/description-courte # correction de bug
|
||
|
|
git checkout -b docs/description-courte # documentation
|
||
|
|
```
|
||
|
|
|
||
|
|
### 2. Développer et tester
|
||
|
|
|
||
|
|
- Lancer les tests avant de pousser : `make test`
|
||
|
|
- Vérifier le lint : `golangci-lint run` / `npm run lint` / `cargo clippy`
|
||
|
|
- Pour les docs : vérifier les `[[wikilinks]]` cassés
|
||
|
|
|
||
|
|
### 3. Commit
|
||
|
|
|
||
|
|
Format des messages :
|
||
|
|
|
||
|
|
```
|
||
|
|
type(scope): description courte
|
||
|
|
|
||
|
|
Corps optionnel expliquant le pourquoi.
|
||
|
|
```
|
||
|
|
|
||
|
|
Types : `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
|
||
|
|
Scopes : `backend`, `stream`, `frontend`, `infra`, `docs`, `hardware`
|
||
|
|
|
||
|
|
Exemples :
|
||
|
|
- `feat(backend): add stem upload endpoint`
|
||
|
|
- `fix(frontend): fix playlist reorder drag-drop`
|
||
|
|
- `docs(infra): add deployment procedures`
|
||
|
|
|
||
|
|
### 4. Pull Request
|
||
|
|
|
||
|
|
- Titre clair et concis (< 70 caractères)
|
||
|
|
- Description : ce que fait la PR, pourquoi, comment tester
|
||
|
|
- Lier à l'issue correspondante
|
||
|
|
- Attendre la review avant merge
|
||
|
|
|
||
|
|
### 5. Review
|
||
|
|
|
||
|
|
Critères de review :
|
||
|
|
- Le code fait ce qui est décrit
|
||
|
|
- Les tests passent
|
||
|
|
- Pas de régression de sécurité (OWASP top 10)
|
||
|
|
- Cohérent avec l'architecture existante
|
||
|
|
- Pas de dépendance cloud ajoutée (self-hosted only)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Code de conduite
|
||
|
|
|
||
|
|
Résumé des principes du [[00_META/Manifeste/MANIFESTE_ETHIQUE_TALAS]] appliqués à la contribution :
|
||
|
|
|
||
|
|
1. **Respect** — Feedback constructif, pas de jugement personnel
|
||
|
|
2. **Transparence** — Expliquer ses choix techniques, documenter les décisions
|
||
|
|
3. **Pas de dark patterns** — Jamais de code manipulatif (fausse rareté, notifications FOMO, tracking comportemental)
|
||
|
|
4. **Pas de tracking** — Pas de Google Analytics, Facebook Pixel, ou équivalent. Jamais.
|
||
|
|
5. **Self-hosted** — Pas de dépendance à des services cloud tiers (pas d'AWS, Cloudflare, SaaS)
|
||
|
|
6. **Vie privée** — Collecte minimale de données. Export/suppression à tout moment.
|
||
|
|
7. **Bienveillance** — On part du principe que les gens sont là pour aider
|
||
|
|
|
||
|
|
**Comportements inacceptables :** harcèlement, discrimination, trolling, spam, publication de contenu inapproprié.
|
||
|
|
|
||
|
|
En cas de conflit : contacter le mainteneur principal. Les décisions de modération sont finales.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Licences
|
||
|
|
|
||
|
|
| Élément | Licence | Implication |
|
||
|
|
|---------|---------|-------------|
|
||
|
|
| **Code Veza** | Propriétaire | Le code de Veza n'est pas open-source. |
|
||
|
|
| **Hardware** (schémas, PCB, BOM) | CERN-OHL-W 2.0 | Weakly reciprocal : les modifications des fichiers doivent être partagées, mais les projets dérivés peuvent utiliser d'autres licences. |
|
||
|
|
| **Documentation** | CC BY-SA 4.0 | Attribution + partage dans les mêmes conditions. |
|
||
|
|
| **Samples et presets** communautaires | CC BY-SA 4.0 ou CC0 | Selon le choix du créateur. |
|
||
|
|
|
||
|
|
Le détail complet de la frontière commons/commercial est dans [[00_META/CHARTE_OPEN_CORE]].
|
||
|
|
|
||
|
|
**Règle d'or :** un élément classé commons ne peut JAMAIS devenir commercial. L'inverse (ouvrir ce qui était commercial) est encouragé.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Voir aussi
|
||
|
|
|
||
|
|
- [[00_META/Manifeste/MANIFESTE_ETHIQUE_TALAS]] — Engagements éthiques
|
||
|
|
- [[00_META/CHARTE_OPEN_CORE]] — Frontière commons / commercial
|
||
|
|
- [[03_APPS_&_SERVICES/ARCHITECTURE_VEZA]] — Architecture applicative
|
||
|
|
- [[04_INFRA_DEPLOIEMENT/CI_CD/PROCEDURES_DEPLOIEMENT]] — Setup développeur et déploiement
|
||
|
|
- [[00_META/Glossaire/GLOSSAIRE_TALAS]] — Glossaire des termes
|
||
|
|
- [[12_DOCUMENTATION/INDEX_DOCUMENTATION]] — Index de toute la documentation
|