Files
billisdead c70d594292 CONTRIBUTING : procédure formalisée + README : soutien remonté
- CONTRIBUTING.md : section "Proposer une contribution" réécrite avec
  tableaux Markdown, blocs de code inline (convention branches, commits,
  template PR), règles backend/frontend détaillées
- README.md : mention financement déplacée juste après la présentation,
  avant la section Fonctionnalités ; section Soutenir le projet supprimée
  en fin de fichier

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-23 14:50:34 +02:00

4.2 KiB

Contribuer à La Voix du Peuple

Merci de l'intérêt pour le projet. Ce document décrit comment signaler un problème ou proposer une contribution.


Dépôts

Le dépôt source est hébergé sur Gitea (instance privée). GitHub est un miroir public en lecture seule. Les pull requests doivent être soumises sur le miroir GitHub — elles seront intégrées manuellement dans le dépôt source après relecture.


Signaler un bug

Avant d'ouvrir une issue, vérifier qu'elle n'existe pas déjà.

Champ Ce qu'on attend
Version / commit Le hash court du commit concerné (git log --oneline -1) ou le numéro de version
Étapes pour reproduire Séquence minimale et reproductible menant au bug
Comportement observé Ce qui se passe réellement (inclure les messages d'erreur, logs backend)
Comportement attendu Ce qui devrait se passer
Contexte OS, navigateur (pour les bugs frontend), version Python/Node si pertinent

Pour les failles de sécurité, ne pas ouvrir d'issue publique. Contacter directement l'auteur.


Proposer une contribution

1. Discuter avant de coder

Ouvrir une issue pour décrire la modification envisagée, sauf pour les corrections triviales (faute d'orthographe, lien cassé, coquille dans la doc). Cela évite de travailler dans le vide si la direction ne correspond pas au projet.

2. Préparer l'environnement

# Forker le dépôt sur GitHub, puis cloner votre fork
git clone https://github.com/<votre-pseudo>/la-voix-du-peuple.git
cd la-voix-du-peuple

# Créer une branche nommée selon la convention ci-dessous
git checkout -b fix/description-courte
# ou
git checkout -b feat/description-courte

Convention de nommage des branches :

Préfixe Usage
fix/ Correction de bug
feat/ Nouvelle fonctionnalité
docs/ Documentation uniquement
refactor/ Refactorisation sans changement de comportement
chore/ Maintenance (dépendances, config, scripts)

3. Conventions de code

Backend (Python)

Règle Détail
Version minimale Python 3.11
Pas d'ORM psycopg2 direct, comme le reste du code
Validation des entrées Toujours via sanitize_text() et validate_idea_input() existants
Nouveaux modules Pas de dépendance externe sans discussion préalable
Secrets Jamais dans le code — variables d'environnement uniquement

Frontend (TypeScript / React)

Règle Détail
Typage TypeScript strict, pas de any
Composants UI shadcn/ui en priorité, pas de librairie tierce sans discussion
Routing Wouter — pas de react-router
État serveur @tanstack/react-query via le client généré dans lib/api-client-react
CSS Tailwind uniquement, pas de CSS inline arbitraire

Commits

Format : type: description courte en impératif présent (anglais)

fix: reject empty author after sanitization
feat: add webhook retry on consultation close
docs: clarify REDIS_URL usage in .env.example

Types valides : fix, feat, docs, refactor, chore, test.

4. Tester manuellement

Toute modification fonctionnelle doit être testable. Décrire dans la PR :

## Test manuel
1. Lancer l'env de dev : `bash scripts/dev-local.sh`
2. Soumettre une contribution via le formulaire
3. Vérifier que [comportement attendu]

Le projet n'a pas de suite de tests automatisés — la description du test manuel dans la PR en tient lieu.

5. Soumettre la pull request

Ouvrir la PR sur le miroir GitHub. Le titre suit la même convention que les commits. Le corps doit contenir :

Section Contenu
Problème Référence à l'issue (Fixes #42) ou description du problème
Solution Approche retenue et pourquoi
Test manuel Étapes pour vérifier le comportement (voir §4)
Impact Changements de comportement visibles, variables d'environnement ajoutées, migrations BDD

Ne pas modifier LICENSE ni les en-têtes de copyright en tête de fichier.


Licence des contributions

En soumettant une contribution, vous acceptez qu'elle soit distribuée sous la licence EUPL-1.2, identique à celle du projet.