# Contribuer au Projet

Merci de vouloir participer ! 🎉

Pour que notre collaboration soit efficace et que le projet reste propre, nous avons mis en place un processus d'aiguillage précis. Merci de le lire avant de soumettre quoi que ce soit.

## 🧭 Aiguillage : Que voulez-vous faire ?

Identifiez votre cas de figure pour connaître la marche à suivre.

### Cas n°1 : La "Broutille" ou le peaufinage (Non bloquant) 🧹

**C'est quoi ?**

- Une faute d'orthographe dans le README ou les textes.
- Un petit défaut d'alignement CSS.
- Une variable mal nommée, du code mort ou un commentaire inutile.
- Bref, tout ce qui n'empêche pas le code de fonctionner.

**👉 La règle :**
**Ne faites pas de Merge Request pour ça.**
Ouvrez plutôt une **Issue** unique.

- Faites une **liste** de tous les petits points que vous avez relevés.
- Cela nous permet de traiter ces corrections en lot (batch) sans polluer l'historique du projet.

---

### Cas n°2 : Le Bug ou le Blocage 🚫

**C'est quoi ?**

- Une fonctionnalité est cassée.
- Une erreur PHP/JS empêche l'utilisation du projet.
- Vous êtes bloqué dans votre développement à cause d'un dysfonctionnement actuel.

**👉 La règle :**
**Contribuez ! Proposez votre correctif (Code).**

- L'objectif est de vous débloquer immédiatement.
- Votre code servira de base : soit il sera fusionné tel quel, soit il nous servira d'exemple pour implémenter le correctif propre rapidement.

**Idéalement, fournissez un bon code, cohérent avec la code base actuelle afin de nous faire gagner du temps**

**⚠️ Convention de nommage des branches (Strict) :**

- Bug classique : `fix/nom-du-bug`
- Bug bloquant / critique : `hotfix/nom-du-blocage`

---

### Cas n°3 : Nouvelle Fonctionnalité (Feature) ✨

**C'est quoi ?**

- Ajouter une option, changer un comportement, refondre une architecture.

**👉 La règle :**
**🛑 Discussion obligatoire avant de coder.**
Ouvrez une Issue pour présenter votre idée. Ne commencez pas le développement avant d'avoir eu un retour de l'équipe. Nous voulons éviter que vous travailliez pour rien si la fonctionnalité ne rentre pas dans la roadmap.

---

## 📝 Résumé de la convention des branches

Lorsque vous proposez du code (Cas n°2 ou n°3 validé), merci de nommer vos branches ainsi :

| Type de changement      | Préfixe de branche | Exemple                       |
| :---------------------- | :----------------- | :---------------------------- |
| Bug standard            | `fix/`             | `fix/correction-upload-image` |
| **Bloquant / Urgent**   | `hotfix/`          | `hotfix/fatal-error-php8`     |
| Nouvelle fonctionnalité | `feat/`            | `feat/ajout-mode-sombre`      |

## 🛠 Procédure technique (Workflow)

Nous utilisons le workflow classique de GitLab :

1.  **Forkez** le projet (bouton "Fork" en haut à droite).
2.  **Clonez** votre fork en local.
3.  **Ajoutez le dépôt original comme remote `upstream`** (à faire une seule fois) :
    ```bash
    git remote add upstream https://gitlab.com/devopress/framework/elementum.git
    ```
4.  Créez une **branche** pour votre modification (`git checkout -b fix/mon-fix-css` ou `feat/ma-super-feature`).
    - _Jamais de commit direct sur `main` !_
5.  Faites vos modifications.
6.  **Testez** ! (Vérifiez que vous n'avez rien cassé d'autre).
7.  Poussez votre branche.
8.  Ouvrez une **Merge Request** depuis votre fork vers le dépôt original sur la branche `dev`.

### Garder votre fork à jour

Une fois le remote `upstream` configuré (étape 3), vous pouvez synchroniser votre fork avec le dépôt original à tout moment :

```bash
composer run update
```

Cette commande bascule sur `main`, récupère les derniers changements depuis `upstream`, les fusionne, puis pousse le résultat sur votre fork (`origin`). Pensez à l'exécuter régulièrement avant de créer une nouvelle branche.

## ✅ Checklist Qualité

Pour maximiser les chances que votre Merge Request (MR) soit acceptée rapidement, merci de vérifier les points suivants avant de soumettre :

### 🛡️ Sécurité

- [ ] **Permissions :** Les actions sensibles vérifient les droits de l'utilisateur (`User::can()`).

### 💻 Standards de Code & Propreté

- [ ] **Commentaires :** Le code complexe est commenté. Les nouvelles fonctions ont leur bloc PHPDoc complet (paramètres, retour, description).
- [ ] **Nettoyage :** Pas de `var_dump`, `console.log`, etc... ou de code commenté laissé à l'abandon.
- [ ] **Nommage :** Les variables et fonctions sont en anglais et nomées explicitement (ex: `getUserData` au lieu de `getData`).

### 🎯 Organisation & Scope

- [ ] **Atomicité :** Cette MR règle **un seul problème** ou ajoute **une seule fonctionnalité**. (Pas de refonte CSS au milieu d'un fix PHP).
- [ ] **Fichiers inutiles :** Je n'ai pas inclus de fichiers de configuration locaux (`.idea`, `.vscode`, `wp-config.php`) ou de fichiers système (`.DS_Store`).

### 📦 Tests & Validation

- [ ] **Test manuel :** J'ai testé ma modification et vérifié qu'elle ne casse pas le reste du site (régression).
- [ ] **Description :** J'ai rempli le modèle de description de la MR en expliquant le _pourquoi_ et le _comment_.

Merci de votre rigueur ! C'est ce qui garde le projet sain. 🏅

Merci de faire vivre ce projet ! ❤️