Repository navigation
contributing FR
Merci de votre intérêt pour contribuer à QElectroTech ! Ce guide explique comment s'impliquer, de la signalisation des bugs à l'écriture de code.
Liens rapides :
- Problèmes à traiter — 30+ problèmes ont besoin d'aide
- Référentiel source — Accueil GitHub
- Forum — Discussion communautaire
- CONTRIBUTING.md — Directives officielles (dans le référentiel)
Vous avez trouvé un problème ? Aidez-nous à le corriger :
- Recherchez les problèmes existants pour éviter les doublons
-
Créez un problème avec :
- Description claire du problème
- Étapes pour reproduire
- Comportement attendu vs réel
- Votre version QET et OS
- Captures d'écran si utile
Vous avez une idée ? Partagez-la :
- Recherchez les discussions pour voir si elle a été discutée
-
Ouvrez une discussion expliquant :
- Ce que vous voulez faire
- Pourquoi ce serait utile
- Toute approche alternative
Aidez à améliorer ce wiki et d'autres documentations :
- Voir Contribution au Wiki
- Aider à traduire la documentation
- Créer des tutoriels ou des guides pour les workflows courants
Partager vos bibliothèques d'éléments avec la communauté :
- Apprenez à créer des éléments
- Publier sur le Référentiel d'Éléments
- Rejoindre l'équipe de maintenance des éléments
Prêt à coder ? Suivez ces étapes :
Vous aurez besoin de :
Compétences en Programmation :
- C++ — QET est écrit en C++ moderne (C++11 et versions ultérieures)
- Framework Qt — Qt 5.x (stable actuel), Qt 6.x (en développement actif)
- Git — Contrôle de version ; essentiel pour la collaboration
Outils et Connaissances :
- Construire QET à partir de la source — Capable de compiler le projet
- CMake — Système de construction utilisé par QET
-
Compréhension de :
- Fondamentaux du Framework Qt (signaux/slots, widgets, modèles)
- Traitement XML (QET utilise XML pour les fichiers)
- La structure du codebase
Recommandé :
- Une certaine familiarité avec les schémas électriques (aide à comprendre le domaine)
- Expérience avec le workflow de contribution open-source
| Composant | Technologie | Utilisation |
|---|---|---|
| Framework GUI | Qt 5.x / Qt 6.x | Interface utilisateur, multi-plateforme |
| Langage | C++ | Logique d'application principale |
| Système de Construction | CMake | Configuration et compilation |
| Tests | Catch2, googletest | Framework de test unitaire |
| Documentation | Doxygen | Génération de documentation API |
| Traductions | Qt Linguist | Internationalisation (i18n) |
| Formats de Fichier | XML | Projets (.qet), éléments (.elmt), blocs de titre |
| VCS | Git | Contrôle de version (GitHub) |
-
Forkez le référentiel sur GitHub :
- Visitez https://github.com/qelectrotech/qelectrotech-source-mirror
- Cliquez sur le bouton "Fork"
- Crée votre propre copie
-
Clonez votre fork localement (avec sous-modules) :
git clone --recursive https://github.com/YOUR_USERNAME/qelectrotech-source-mirror.git cd qelectrotech-source-mirror -
Ajoutez le contrôle à distance upstream pour suivre le référentiel principal :
git remote add upstream https://github.com/qelectrotech/qelectrotech-source-mirror.git
-
Créez une branche de fonctionnalité pour votre travail :
git checkout -b fix/issue-123 # ou git checkout -b feature/ma-fonctionnalite # Nommage de branche : fix/*, feature/*, docs/*, refactor/*, etc.
-
Configurez l'utilisateur Git (s'il n'est pas déjà fait) :
git config user.name "Votre Nom" git config user.email "votre.email@exemple.com"
-
Construire à partir de la source pour assurer que l'environnement fonctionne :
mkdir build && cd build cmake .. cmake --build . --config Release
-
Comprendre le problème/la fonctionnalité :
- Lire le problème GitHub attentivement
- Poster un commentaire si flou ("Je voudrais travailler sur ceci")
- Discuter de l'approche avec les responsables pour les changements majeurs
-
Écrire du code propre et maintenable :
- Suivre le formatage du code : Utiliser
clang-format(configuration incluse) - Un changement logique par commit — ne pas mélanger les correctifs non liés
- Messages de commit significatifs — expliquer POURQUOI, pas juste QUOI
- Commenter légèrement : Seule la logique complexe nécessite des commentaires
- Garder les fonctions concentrées et petites
- Suivre le formatage du code : Utiliser
-
Directives de style de code :
- Nommage : camelCase pour les variables/fonctions, PascalCase pour les classes
-
Formatage : Configuré via le fichier
.clang-format(exécuter avant de committer) - Conventions Qt : Suivre les normes de codage Qt/KDE
- C++ moderne : Utiliser les fonctionnalités C++11/14/17 de façon appropriée
-
Ajouter des tests pour les nouvelles fonctionnalités :
- Framework de test : Catch2 ou googletest
- Écrire des tests unitaires qui vérifient vos modifications
- S'assurer que les tests existants passent toujours :
ctest - Exécuter :
cmake --build . && ctest
-
Créer localement et tester :
cd build cmake --build . --config Release ctest # Exécuter les tests ./qelectrotech # Tester l'application manuellement
-
Gardez votre branche à jour avec upstream :
git fetch upstream git rebase upstream/main # ou fusionner si vous préférez : git merge upstream/main
-
Poussez votre branche vers votre fork :
git push origin fix/issue-123
-
Créez une Pull Request (PR) sur GitHub :
- Allez à votre fork → Bouton "Create Pull Request"
- Titre : Court, descriptif (p. ex., "Corriger la gestion de coordonnées NaN lors du chargement d'éléments")
-
Description : Inclure :
- Quel problème cela résout ?
- Comment votre solution fonctionne-t-elle ?
- Captures d'écran pour les modifications de l'interface
- Tests ajoutés
- Problèmes associés : "Fixes #781" ou "Closes #782"
-
Base : Définir sur la branche
main - Draft PR : Marquer comme Draft si toujours en cours
-
Répondre aux commentaires :
- Les responsables examineront votre code
- Traiter les commentaires et les suggestions
- Pousser des commits supplémentaires à la même branche (met à jour automatiquement la PR)
- Soyez patient et collaboratif
-
Gardez la PR à jour si la branche principale change :
git fetch upstream git rebase upstream/main git push --force-with-lease origin fix/issue-123
-
Célébrez ! 🎉 Une fois approuvée et fusionnée, votre contribution fait partie de QET
QET utilise clang-format pour un style de code cohérent :
# Formater vos fichiers avant de committer
clang-format -i src/mon_fichier.cpp
# ou formater tous les fichiers modifiés
git diff --name-only | xargs clang-format -i- Commentaires en ligne : Uniquement pour la logique non évidente
- Documentation des fonctions : Utiliser le style Doxygen pour les API publiques
- Messages de commit : Clairs, descriptifs, expliquent pourquoi pas juste quoi
- Tests unitaires : Écrire des tests pour les nouvelles fonctionnalités
- Exécuter les tests existants : S'assurer que vous ne cassez rien
- Couverture des tests : Plus de tests = meilleure confiance
Bonne structure de message de commit :
Bref résumé en une ligne (50 caractères ou moins)
Explication plus longue du changement. Expliquez le problème,
votre solution, et tous les compromis ou considérations.
Garder à une largeur de ligne de 72 caractères.
Fixes #123
Exemples :
- ✅ "Corriger la validation de coordonnées NaN lors du chargement d'élément"
- ✅ "Ajouter la fonctionnalité de générateur de bande terminale avec tests"
- ❌ "Correction du bug"
- ❌ "Mise à jour du code"
- Les responsables examineront votre code
- Les commentaires visent à l'amélioration, pas à la critique personnelle
- Soyez ouvert aux suggestions
- Demandez des clarifications si quelque chose n'est pas clair
- Documentation du Développeur — Architecture et référence d'API
- Forum — Posez des questions à la communauté
- GitHub Discussions — Demandes de conception et idées
- Building QET — Instructions de compilation
- Code Examples — Voir comment c'est implémenté
- Soyez respectueux — Nous sommes tous ici pour améliorer QET
- Soyez clair — Expliquez ce que vous essayez d'accomplir
- Demandez de l'aide — Ne pas avoir peur de poser des questions
- Célébrez les contributions — Reconnaître le travail des autres
Vos contributions aident QElectroTech à devenir un meilleur outil pour tous. Que ce soit un correctif de bug, une nouvelle fonctionnalité, une documentation ou une traduction, votre travail est apprécié !
Questions ? Rejoignez le Forum ou posez une question sur GitHub Discussions.
🌐 Choisir la Langue — English · Français · Deutsch
