Files
TechradarDev/docs/app/contribution.md
syoul 055e4a9281 refactor: réorganiser la documentation en séparant app et data
- Création de docs/app/ pour la documentation de l'application
- Création de docs/data/ pour les données utilisées par l'application
- Déplacement de la documentation technique vers docs/app/
- Déplacement des données métier vers docs/data/
- Mise à jour de tous les liens et références dans les fichiers
- Mise à jour des scripts (extract-technologies.js, analyze-business-metrics.js)
- Mise à jour des fichiers JavaScript (custom.js, strategie-link.js)
- Création de README.md dans docs/, docs/app/ et docs/data/
- Mise à jour du Readme.md principal avec les nouveaux chemins
2025-12-03 14:35:36 +01:00

201 lines
5.1 KiB
Markdown

# Guide de contribution
## Vue d'ensemble
Ce guide explique comment contribuer au Technology Radar AJR en ajoutant, modifiant ou supprimant des technologies (blips).
## Processus de contribution
### 1. Préparer l'environnement
Voir le [guide de développement](./developpement.md) pour l'installation et la configuration de l'environnement local.
### 2. Créer une branche
```bash
git checkout -b feature/nom-de-la-technologie
```
### 3. Ajouter ou modifier un blip
#### Ajouter un nouveau blip
1. Créer un fichier Markdown dans le dossier de release approprié :
```
radar/2025-04-10/nom-technologie.md
```
2. Utiliser le format standard :
```markdown
---
title: "Nom de la technologie"
ring: adopt|trial|assess|hold
quadrant: languages-and-frameworks|methods-and-patterns|platforms-and-aoe-services|tools
tags: [tag1, tag2]
---
Description de la technologie.
## Avantages
- Point 1
- Point 2
## Cas d'usage AJR
Description de l'utilisation chez AJR.
```
#### Modifier un blip existant
1. Localiser le fichier dans le dossier de release
2. Modifier le contenu ou les métadonnées
3. Si vous changez le ring ou le quadrant, documenter la raison
#### Supprimer un blip
Si une technologie doit être retirée du radar :
- La déplacer vers le ring "hold" plutôt que de la supprimer
- Ou la supprimer complètement si elle n'est plus pertinente
### 4. Tester localement
```bash
npm run serve
```
Vérifier :
- L'affichage correct du blip
- Le positionnement dans le bon quadrant et ring
- La lisibilité du contenu
- Le fonctionnement des tags
### 5. Commiter les changements
```bash
git add radar/2025-04-10/nom-technologie.md
git commit -m "feat: ajouter [technologie] au quadrant [quadrant]"
```
### 6. Pousser et créer une pull request
```bash
git push origin feature/nom-de-la-technologie
```
Créer une pull request sur le dépôt Git.
## Guidelines de contenu
### Choix du ring
- **Adopt** : Technologie utilisée avec succès dans plusieurs projets, stable et recommandée
- **Trial** : Technologie testée avec succès, à considérer pour de nouveaux projets
- **Assess** : Technologie prometteuse, à évaluer selon les besoins
- **Hold** : Technologie à éviter ou à remplacer, mais peut être maintenue dans les projets existants
### Choix du quadrant
- **Languages & Frameworks** : Langages de programmation et frameworks de développement
- **Methods & Patterns** : Méthodologies, patterns architecturaux, pratiques de développement
- **Platforms & Operations** : Plateformes cloud, infrastructure, services opérationnels
- **Tools** : Outils de développement, utilitaires, logiciels
### Tags
Utiliser les tags établis :
- architecture
- security
- devops
- frontend
- agile
- coding
- quality assurance
- ci/cd
- ux/ui
- documentation
Ajouter plusieurs tags si la technologie couvre plusieurs domaines.
### Qualité du contenu
- **Clarté** : Description claire et concise
- **Pertinence** : Focus sur l'utilisation chez AJR
- **Objectivité** : Présenter les avantages et inconvénients
- **Concision** : Rester factuel et éviter les détails superflus
## Format des commits
Utiliser des messages de commit clairs :
```
feat: ajouter [technologie] au quadrant [quadrant]
fix: corriger la description de [technologie]
update: déplacer [technologie] de trial à adopt
docs: améliorer la documentation de [technologie]
```
## Créer une nouvelle release
Quand créer une nouvelle release :
1. **Périodicité** : Généralement tous les 3-6 mois
2. **Changements significatifs** : Plusieurs nouveaux blips ou changements majeurs
3. **Événements** : Après des évaluations importantes
### Processus de release
1. Créer un nouveau dossier avec la date :
```bash
mkdir radar/2025-07-15
```
2. Copier les blips pertinents depuis la release précédente
3. Ajouter les nouveaux blips
4. Mettre à jour les blips existants si nécessaire
5. Documenter les changements majeurs
## Review process
Les contributions sont revues pour :
- **Exactitude** : Les informations sont correctes
- **Pertinence** : La technologie est pertinente pour AJR
- **Format** : Le format Markdown est correct
- **Classification** : Le ring et quadrant sont appropriés
- **Qualité** : Le contenu est clair et utile
## Questions fréquentes
### Puis-je ajouter une technologie que je n'ai pas encore utilisée ?
Non. Le radar ne contient que des technologies testées au moins une fois par l'équipe.
### Comment décider entre deux quadrants ?
Choisir le quadrant le plus approprié. Si c'est ambigu, discuter avec l'équipe.
### Puis-je modifier un blip d'une release précédente ?
Généralement non. Les releases précédentes sont figées. Créer un nouveau blip dans la release actuelle si nécessaire.
### Comment gérer les technologies obsolètes ?
Les déplacer vers le ring "hold" avec une explication de pourquoi elles ne sont plus recommandées.
## Ressources
- [Guide de développement](./developpement.md)
- [Configuration](./configuration.md)
- [Architecture](./architecture.md)
- Framework source : https://github.com/AOEpeople/aoe_technology_radar
## Contact
Pour toute question sur les contributions, contacter l'équipe AJR ou ouvrir une issue sur le dépôt Git.