4NK_template/CONTRIBUTING.md

Guide de Contribution - 4NK Node

Merci de votre intérêt pour contribuer au projet 4NK Node ! Ce guide vous aidera à comprendre comment participer au développement de cette infrastructure pour les paiements silencieux Bitcoin.

📋 Table des Matières

• 🎯 Comment Contribuer
• 🚀 Premiers Pas
• 🔧 Environnement de Développement
• 📝 Processus de Contribution
• 🧪 Tests
• 📚 Documentation
• 🐛 Signaler un Bug
• 💡 Proposer une Fonctionnalité
• 🔍 Code Review
• 📦 Release

🎯 Comment Contribuer

Types de Contributions

Nous accueillons différents types de contributions :

• 🐛 Bug fixes - Correction de bugs et problèmes
• ✨ Nouvelles fonctionnalités - Ajout de nouvelles capacités
• 📚 Documentation - Amélioration de la documentation
• 🧪 Tests - Ajout ou amélioration des tests
• 🔧 Outils - Amélioration des scripts et outils
• 🌐 Traductions - Traduction de la documentation
• 📊 Performance - Optimisations de performance
• 🔒 Sécurité - Améliorations de sécurité

Niveaux de Contribution

• Débutant - Documentation, tests, petits bugs
• Intermédiaire - Nouvelles fonctionnalités, améliorations
• Avancé - Architecture, optimisations majeures

🚀 Premiers Pas

Prérequis

• Docker et Docker Compose installés
• Git configuré
• Python 3.8+ (pour les tests)
• Rust (pour le développement sdk_relay)
• Connexion Internet stable

Fork et Clone

# 1. Fork le repository sur Gitea
# 2. Clone votre fork
git clone https://git.4nkweb.com/votre-username/4NK_node.git
cd 4NK_node

# 3. Ajouter le repository original comme upstream
git remote add upstream https://git.4nkweb.com/4nk/4NK_node.git

Branches

# Créer une branche pour votre contribution
git checkout -b feature/nom-de-votre-feature
# ou
git checkout -b fix/nom-du-bug

🔧 Environnement de Développement

Installation Locale

# 1. Cloner le repository
git clone https://git.4nkweb.com/4nk/4NK_node.git
cd 4NK_node

# 2. Démarrer l'infrastructure
./restart_4nk_node.sh

# 3. Vérifier que tout fonctionne
docker ps

Configuration de Développement

# Variables d'environnement pour le développement
export RUST_LOG=debug
export ENABLE_SYNC_TEST=1
export BITCOIN_NETWORK=signet

Outils de Développement

# Tests
./tests/run_all_tests.sh

# Linting (si configuré)
cargo clippy
rustfmt src/

# Build
docker-compose build

📝 Processus de Contribution

1. Planifier Votre Contribution

• Vérifier les issues existantes
• Créer une issue si nécessaire
• Discuter de l'approche avec l'équipe
• Planifier les tests et la documentation

2. Développer

• Créer une branche depuis main
• Développer votre fonctionnalité
• Ajouter des tests
• Mettre à jour la documentation
• Vérifier que les tests passent

3. Soumettre

• Commiter avec des messages clairs
• Pousser vers votre fork
• Créer une Pull Request
• Remplir le template de PR

Messages de Commit

Utilisez le format conventionnel :

# Format
type(scope): description

# Exemples
feat(sdk_relay): add new sync type for metrics
fix(bitcoin): resolve connection timeout issue
docs(api): update WebSocket message format
test(integration): add multi-relay sync tests

Types

• feat - Nouvelle fonctionnalité
• fix - Correction de bug
• docs - Documentation
• style - Formatage
• refactor - Refactoring
• test - Tests
• chore - Maintenance

🧪 Tests

Exécuter les Tests

# Tous les tests
./tests/run_all_tests.sh

# Tests par catégorie
./tests/run_unit_tests.sh
./tests/run_integration_tests.sh
./tests/run_connectivity_tests.sh
./tests/run_external_tests.sh

# Tests avec debug
./tests/run_all_tests.sh --debug

Ajouter des Tests

# Structure recommandée
tests/
├── unit/           # Tests unitaires
├── integration/    # Tests d'intégration
├── connectivity/   # Tests de connectivité
├── external/       # Tests externes
└── performance/    # Tests de performance

Bonnes Pratiques

• Testez tous les cas d'usage
• Incluez des tests d'erreur
• Maintenez une couverture > 80%
• Utilisez des données de test réalistes

📚 Documentation

Mise à Jour de la Documentation

# Structure de la documentation
docs/
├── INSTALLATION.md    # Guide d'installation
├── USAGE.md          # Guide d'utilisation
├── CONFIGURATION.md  # Guide de configuration
├── ARCHITECTURE.md   # Architecture technique
├── API.md           # Référence API
├── TESTING.md       # Guide des tests
└── INDEX.md         # Index principal

Standards de Documentation

• Utilisez le Markdown
• Incluez des exemples de code
• Ajoutez des diagrammes si nécessaire
• Maintenez la cohérence du style
• Traduisez en anglais si possible

🐛 Signaler un Bug

Template de Bug Report

## Description du Bug

Description claire et concise du problème.

## Étapes pour Reproduire

1. Aller à '...'
2. Cliquer sur '...'
3. Faire défiler jusqu'à '...'
4. Voir l'erreur

## Comportement Attendu

Description de ce qui devrait se passer.

## Comportement Actuel

Description de ce qui se passe actuellement.

## Informations Système

- OS: [ex: Ubuntu 20.04]
- Docker: [ex: 20.10.0]
- Version: [ex: v1.0.0]

## Logs

Logs pertinents ici

## Capture d'Écran

Si applicable, ajoutez une capture d'écran.

## Contexte Supplémentaire

Toute autre information pertinente.

💡 Proposer une Fonctionnalité

Template de Feature Request

## Résumé

Description claire et concise de la fonctionnalité souhaitée.

## Motivation

Pourquoi cette fonctionnalité est-elle nécessaire ?

## Proposition

Description détaillée de la fonctionnalité proposée.

## Alternatives Considérées

Autres solutions envisagées.

## Impact

Impact sur les utilisateurs et l'architecture.

## Exemples d'Utilisation

Comment cette fonctionnalité serait-elle utilisée ?

🔍 Code Review

Processus de Review

1. Automatique - Tests et linting
2. Review par l'équipe - Code review manuel
3. Tests d'intégration - Validation complète
4. Approbation - Merge dans main

Critères de Review

• Code fonctionnel et testé
• Tests ajoutés/modifiés
• Documentation mise à jour
• Pas de régression
• Performance acceptable
• Sécurité vérifiée

Répondre aux Reviews

• Répondez poliment aux commentaires
• Apportez les modifications demandées
• Demandez des clarifications si nécessaire
• Re-merguez après les corrections

📦 Release

Processus de Release

1. Préparation - Finaliser les fonctionnalités
2. Tests - Tests complets
3. Documentation - Mise à jour des docs
4. Tag - Créer un tag de version
5. Release - Publier sur GitHub/GitLab
6. Annonce - Communiquer la release

Numérotation des Versions

Utilisez le Semantic Versioning :

• MAJOR - Changements incompatibles
• MINOR - Nouvelles fonctionnalités compatibles
• PATCH - Corrections de bugs compatibles

🤝 Communauté

Communication

• Issues - Pour les bugs et fonctionnalités
• Discussions - Pour les questions générales (via les issues)
• Pull Requests - Pour les contributions
• Wiki - Pour la documentation collaborative (si activé sur Gitea)

Code de Conduite

• Soyez respectueux et inclusif
• Écoutez les autres points de vue
• Contribuez de manière constructive
• Respectez les standards du projet

Reconnaissance

• Les contributeurs sont listés dans le README
• Les contributions significatives sont reconnues
• Les releases mentionnent les contributeurs

🆘 Besoin d'Aide ?

• Consultez la documentation
• Vérifiez les issues existantes
• Posez une question via les issues
• Contactez l'équipe de maintenance

📄 Licence

En contribuant, vous acceptez que vos contributions soient sous la même licence que le projet (MIT).

---

Merci de contribuer à 4NK Node ! 🚀