afterwork/CONTRIBUTING.md

# 🤝 Guide de Contribution - AfterWork

Merci de votre intérêt pour contribuer au projet AfterWork ! Ce document vous guidera à travers le processus de contribution.

## 📋 Table des Matières

- [Code de Conduite](#code-de-conduite)
- [Comment Contribuer](#comment-contribuer)
- [Standards de Code](#standards-de-code)
- [Processus de Pull Request](#processus-de-pull-request)
- [Conventions de Commit](#conventions-de-commit)
- [Architecture du Projet](#architecture-du-projet)

---

## 📜 Code de Conduite

En participant à ce projet, vous acceptez de respecter notre code de conduite :

- Être respectueux envers tous les contributeurs
- Accepter les critiques constructives
- Se concentrer sur ce qui est le mieux pour la communauté
- Faire preuve d'empathie envers les autres membres

---

## 🚀 Comment Contribuer

### 1. Fork et Clone

```bash
# Fork le repository sur GitHub
# Puis clone votre fork
git clone https://github.com/votre-username/afterwork.git
cd afterwork
```

### 2. Créer une Branche

```bash
# Créer une branche pour votre feature/fix
git checkout -b feature/nom-de-votre-feature

# Ou pour un bugfix
git checkout -b fix/nom-du-bug
```

### 3. Développer

- Écrivez du code propre et testé
- Suivez les standards de code du projet
- Ajoutez des tests pour les nouvelles fonctionnalités
- Documentez votre code

### 4. Tester

```bash
# Lancer les tests
flutter test

# Vérifier le linting
flutter analyze

# Formater le code
dart format .
```

### 5. Commit

```bash
# Ajouter vos changements
git add .

# Commit avec un message descriptif
git commit -m "feat: ajouter fonctionnalité X"
```

### 6. Push et Pull Request

```bash
# Push vers votre fork
git push origin feature/nom-de-votre-feature

# Créer une Pull Request sur GitHub
```

---

## 💻 Standards de Code

### Formatage

- **Indentation** : 2 espaces
- **Ligne max** : 80 caractères (flexible pour la lisibilité)
- **Trailing commas** : Obligatoires pour les listes multi-lignes

### Conventions de Nommage

```dart
// Classes : PascalCase
class UserProfile {}

// Fichiers : snake_case
// user_profile.dart

// Variables et fonctions : camelCase
String userName = 'John';
void getUserById() {}

// Constantes : lowerCamelCase
const String apiBaseUrl = 'https://api.example.com';

// Constantes privées : _lowerCamelCase
const String _privateKey = 'secret';
```

### Widgets

```dart
// Toujours utiliser const pour les widgets immuables
const Text('Hello World');

// Préférer les constructeurs const
class MyWidget extends StatelessWidget {
  const MyWidget({super.key});
  
  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

// Trailing comma pour meilleure lisibilité
return Container(
  padding: const EdgeInsets.all(16),
  child: Column(
    children: [
      const Text('Title'),
      const SizedBox(height: 8),
      const Text('Subtitle'),
    ],
  ),
);
```

### Documentation

```dart
/// Récupère un utilisateur par son ID.
///
/// [userId] L'identifiant unique de l'utilisateur.
/// 
/// Retourne un [User] ou null si non trouvé.
/// 
/// Throws [ServerException] si l'API est inaccessible.
Future<User?> getUserById(String userId) async {
  // Implementation
}
```

### Gestion des Erreurs

```dart
// Utiliser try-catch pour les opérations à risque
try {
  final result = await apiCall();
  return Right(result);
} on ServerException catch (e) {
  return Left(ServerFailure(e.message));
} catch (e) {
  return Left(UnexpectedFailure());
}
```

---

## 🔄 Processus de Pull Request

### Checklist avant PR

- [ ] Le code compile sans erreur
- [ ] Tous les tests passent (`flutter test`)
- [ ] Le linting est propre (`flutter analyze`)
- [ ] Le code est formaté (`dart format .`)
- [ ] Les nouvelles fonctionnalités ont des tests
- [ ] La documentation est à jour
- [ ] Les commits suivent les conventions

### Template de PR

```markdown
## Description
Brève description des changements

## Type de changement
- [ ] Bug fix
- [ ] Nouvelle fonctionnalité
- [ ] Breaking change
- [ ] Documentation

## Tests
- [ ] Tests unitaires ajoutés/mis à jour
- [ ] Tests d'intégration ajoutés/mis à jour
- [ ] Tests manuels effectués

## Captures d'écran (si applicable)
Ajoutez des captures d'écran ici

## Checklist
- [ ] Mon code suit les standards du projet
- [ ] J'ai effectué une auto-review
- [ ] J'ai commenté les parties complexes
- [ ] J'ai mis à jour la documentation
- [ ] Mes changements ne génèrent pas de warnings
- [ ] J'ai ajouté des tests
- [ ] Tous les tests passent
```

---

## 📝 Conventions de Commit

Nous utilisons les [Conventional Commits](https://www.conventionalcommits.org/) :

### Format

```
<type>(<scope>): <subject>

<body>

<footer>
```

### Types

- **feat** : Nouvelle fonctionnalité
- **fix** : Correction de bug
- **docs** : Documentation uniquement
- **style** : Formatage, points-virgules manquants, etc.
- **refactor** : Refactoring de code
- **perf** : Amélioration de performance
- **test** : Ajout ou correction de tests
- **chore** : Maintenance, dépendances, etc.

### Exemples

```bash
# Feature
git commit -m "feat(auth): ajouter authentification biométrique"

# Bug fix
git commit -m "fix(events): corriger crash lors du chargement"

# Documentation
git commit -m "docs(readme): mettre à jour instructions d'installation"

# Refactoring
git commit -m "refactor(user): extraire logique de validation"

# Breaking change
git commit -m "feat(api): changer format de réponse

BREAKING CHANGE: Le format de réponse de l'API a changé"
```

---

## 🏗 Architecture du Projet

### Clean Architecture

Le projet suit les principes de Clean Architecture :

```
lib/
├── core/           # Code partagé (constantes, utils, thèmes)
├── domain/         # Logique métier pure (entités, usecases)
├── data/           # Implémentation data (models, repositories)
└── presentation/   # UI (screens, widgets, state management)
```

### Règles

1. **Domain** ne dépend de rien
2. **Data** dépend de Domain
3. **Presentation** dépend de Domain (et peut utiliser Data via interfaces)
4. Les dépendances pointent toujours vers l'intérieur

### Exemple d'ajout de fonctionnalité

1. **Créer l'entité** dans `domain/entities/`
2. **Créer le use case** dans `domain/usecases/`
3. **Créer le modèle** dans `data/models/`
4. **Créer le repository** dans `data/repositories/`
5. **Créer le BLoC/Provider** dans `presentation/state_management/`
6. **Créer l'UI** dans `presentation/screens/` ou `presentation/widgets/`

---

## 🧪 Tests

### Structure des Tests

```
test/
├── domain/
│   ├── entities/
│   └── usecases/
├── data/
│   ├── models/
│   └── repositories/
└── presentation/
    ├── screens/
    └── widgets/
```

### Exemple de Test Unitaire

```dart
import 'package:flutter_test/flutter_test.dart';

void main() {
  group('User Entity', () {
    test('should create user with valid data', () {
      // Arrange
      const userId = '123';
      const email = 'test@example.com';
      
      // Act
      final user = User(
        userId: userId,
        email: email,
        // ...
      );
      
      // Assert
      expect(user.userId, userId);
      expect(user.email, email);
    });
  });
}
```

---

## 📚 Ressources

- [Flutter Documentation](https://flutter.dev/docs)
- [Dart Style Guide](https://dart.dev/guides/language/effective-dart/style)
- [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
- [BLoC Pattern](https://bloclibrary.dev/)

---

## ❓ Questions

Si vous avez des questions, n'hésitez pas à :
- Ouvrir une issue
- Contacter l'équipe de développement

---

**Merci de contribuer à AfterWork ! 🚀**