nicolas.cantu/4NK_project_template
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4NK_project_template/CONTRIBUTING.md
Nicolas Cantu 6f16f16353 init
2025-08-25 17:27:12 +02:00

8.4 KiB
Raw Permalink Blame History

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

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 ?

📄 Licence

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

Merci de contribuer à 4NK Node ! 🚀