- 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
201 lines
5.1 KiB
Markdown
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.
|
|
|