Contribuer aux documents

​

Donner un retour

​

Sur n’importe quelle page

• Votes Positif/Négatif — Retour rapide sur si la page était utile
• Commentaires — Partagez des retours, des suggestions ou des questions spécifiques
• Signaler un problème — Signalez des erreurs, des informations obsolètes ou des liens cassés

​

Canaux de retours généraux

• Problèmes GitHub — Ouvrir un problème dans leLivepeer Dépôt de documentation
• Discord — Partager des retours dans le Discord de la communauté Livepeer
• Email — Contactez l’équipe de documentation directement

​

Contribuer aux Docs

​

Contributions non techniques

​

Option 1 : Formulaire de feedback

​

Option 2 : Suggestions de contenu

• Identifier les domaines nécessitant une clarification
• Suggérer de nouveaux sujets ou tutoriels
• Signaler les informations obsolètes
• Partager des cas d’utilisation ou des exemples

​

Contributions techniques (Git et Markdown)

​

Processus de Pull Request

​

Guide étape par étape

​

1. Fork du dépôt

1. Naviguer versgithub.com/livepeer/docs
2. Cliquez sur le bouton “Fork” en haut à droite
3. Cela crée une copie de votre propre dépôt

​

2. Cloner votre fork

git clone https://github.com/YOUR_USERNAME/docs.git
cd docs

​

3. Configurer le suivi à distance

# Add the original repository as upstream
git remote add upstream https://github.com/livepeer/docs.git

# Verify remotes
git remote -v

​

4. Créer une branche

# Make sure you're on the latest version
git checkout docs-v2-preview
git pull upstream docs-v2-preview

# Create a new branch with a descriptive name
git checkout -b docs/fix-typo-quickstart-guide
# or
git checkout -b docs/add-api-example
# or
git checkout -b docs/update-component-docs

• docs/préfixe pour les modifications de documentation
• Utilisez des noms descriptifs : docs/fix-typo-quickstart-guide
• Utilisez le kebab-case (minuscules avec des tirets)

​

5. Installer les hooks de pré-validation

# Install the pre-commit hook
./.githooks/install.sh

• Vérifier les ThemeData utilisation
• Avertir sur les couleurs hexadécimales codées en dur
• Valider la syntaxe MDX, JSON et JavaScript
• Vérifier les imports relatifs
• Vérifier les chemins d’importation absolus

​

6. Apportez vos modifications

• Pages principales de la documentation : v2/pages/ (organisées par section)
• Composants : snippets/components/
• Fichiers de données : snippets/data/
• Actifs : snippets/assets/

v2/pages/
├── home/          # Home tab content
├── about/         # About tab content
├── developers/    # Developers tab content
├── gateways/      # Gateways tab content
├── orchestrators/ # Orchestrators tab content
├── delegators/    # Delegators tab content
├── community/     # Community tab content
├── resources/     # Resources tab content
└── internal/      # Internal documentation

• Utilisez le kebab-case pour les noms de fichiers : quickstart-guide.mdx
• Utilisez des noms descriptifs qui reflètent le contenu
• Suivez la structure existante dans chaque section

​

7. Tester localement

# Install Mintlify CLI (if not already installed)
npm i -g mintlify

# Run the development server
mint dev

• ✅ Les pages s’affichent correctement
• ✅ Aucun erreur dans la console
• ✅ Les liens fonctionnent correctement
• ✅ Les composants s’affichent correctement
• ✅ Les modes clair et sombre fonctionnent
• ✅ Réactivité mobile

​

8. Validez vos modifications

# Stage your changes
git add .

# Commit with a clear message
git commit -m "docs: fix typo in quickstart guide"

• Utilisez des préfixes : docs:, fix:, feat:, chore:
• Soyez descriptifs : “docs : ajouter un exemple d’authentification API”
• Référencez les problèmes : “docs : mettre à jour la configuration du gateway (résout #123)”

git commit -m "Update .allowlist" --trailer "allowlist-edit=true"

git commit -m "Remove obsolete files" --trailer "allow-deletions=true"

​

9. Pousser vers votre fork

git push origin docs/your-branch-name

​

10. Créer une demande de tirage

1. Accédez àgithub.com/livepeer/docs
2. Vous devriez voir une bannière suggérant de créer une PR à partir de votre poussée récente
3. Cliquez sur « Comparer et créer la demande de tirage »
4. Remplissez le modèle de demande de tirage :
   • **Titre :**Titre clair et descriptif
   • **Description :**Expliquez ce que vous avez changé et pourquoi
   • **Problèmes liés :**Lien vers tout problème lié
   • Type : Marquer comme modification de documentation
   • Test : Décrire comment vous avez testé

## Description
Brief description of changes

## Type of Change
- [ ] Bug fix (typo, broken link, incorrect information)
- [ ] New content (guide, tutorial, example)
- [ ] Content improvement (clarification, better examples)
- [ ] Component or styling update

## Related Issues
Fixes #123

## Testing
- [ ] Tested locally with `mint dev`
- [ ] Checked light and dark modes
- [ ] Verified all links work
- [ ] No console errors

​

11. Traiter les commentaires de révision

• Répondre aux commentaires
• Apporter les modifications demandées
• Soumettre les mises à jour sur la même branche (elles apparaîtront automatiquement dans la PR)
• Marquer les conversations comme résolues une fois terminées

​

12. Fusionner et nettoyer

• Supprimez votre branche localement : git branch -d docs/your-branch-name
• Supprimez votre branche sur GitHub (option disponible après fusion)
• Mettez à jour votre fork : git checkout docs-v2-preview && git pull upstream docs-v2-preview

​

Configuration de développement

​

Prérequis

• Node.js (version 18 ou supérieure recommandée)
• Git
• compte GitHub

​

Installation

# Clone the repository
git clone https://github.com/livepeer/docs.git
cd docs

# Install Mintlify CLI globally
npm i -g mintlify

# Install pre-commit hooks
./.githooks/install.sh

​

Exécution localement

# Start development server
mint dev

# Server runs on http://localhost:3000 by default

​

Structure du projet

docs/
├── v2/pages/              # Main documentation pages (MDX)
├── snippets/              # Reusable components and data
│   ├── components/        # React/JSX components
│   ├── data/             # Data files (JSX)
│   ├── assets/           # Images, logos, media
│   └── scripts/          # Automation scripts
├── .github/              # GitHub Actions workflows
├── .githooks/            # Pre-commit hooks
├── docs.json             # Mintlify navigation config
└── style.css             # Global CSS variables

​

Guidelines de contribution

​

Guide de style

• ✅ Utiliser les propriétés CSS personnalisées (var(--accent)) uniquement
• ❌ Ne jamais utiliser ThemeData ou définir les couleurs en dur
• ✅ Utiliser des imports absolus : /snippets/components/...
• ❌ Pas d’imports relatifs pour les extraits
• ✅ Tester en mode clair et en mode sombre

​

Utilisation du composant

• Utiliser les composants de la Bibliothèque de composants
• Consultez la documentation du composant avant de créer de nouveaux composants
• Suivez les modèles et les conventions existants

​

Guidelines pour le contenu

• Soyez clair et concis — Écrivez pour votre public
• Utilisez des exemples — Montrez, ne dites pas seulement
• Tenez-le à jour — Supprimez les informations obsolètes
• Liez correctement — Utilisez des liens internes vers du contenu lié
• Ajouter des mots-clés — Aide à la découverte

​

Exemples de code

• Utiliser une mise en évidence de syntaxe appropriée
• Inclure des exemples complets et exécutables lorsqu’ils sont disponibles
• Expliquer ce que fait le code
• Afficher la sortie attendue lorsqu’elle est pertinente

​

Exigences de test

• Toutes les pages s’affichent sans erreur
• Aucune erreur dans la console du navigateur
• Les liens fonctionnent correctement
• Les composants s’affichent correctement
• Fonctionne en mode clair et en mode sombre
• Réactif sur mobile
• Les hooks de pré-validation passent

​

Processus de révision

​

Qui révise quoi

• Section développeurs : Équipe relations développeurs
• Section des passerelles : Équipe des passerelles
• Section des orchestrateurs : Équipe des orchestrateurs
• Section des délégués : Équipe des délégués
• **Section Ressources :**Équipe de documentation
• **Général/Transversal :**Équipe de documentation

​

Calendrier de révision

• Petites modifications (fautes de frappe, liens cassés) : généralement examiné en 24 heures
• Modifications sur Medium (mises à jour du contenu, exemples) : 48-72 heures
• Grandes modifications (nouveaux tutoriels, réorganisation majeure) : peut prendre plus de temps, discutez-en en premier dans l’incident

​

Critères d’examen

• ✅ Précision et exactitude
• ✅ Conformité au guide de style
• ✅ Utilisation correcte des composants
• ✅ Liens et exemples fonctionnels
• ✅ Ton et clarté appropriés
• ✅ SEO et visibilité

​

Traitement des commentaires

• Répondre à tous les commentaires
• Apporter les modifications demandées ou expliquer pourquoi elles ne sont pas apportées
• Soumettre les mises à jour sur la même branche
• Marquer les conversations comme résolues
• Demander une révision lorsque prêt

​

Ce que vous pouvez contribuer

​

Améliorations du contenu

• Corriger les fautes de frappe et les erreurs grammaticales
• Clarifier les explications ambiguës
• Mettre à jour les informations obsolètes
• Améliorer les exemples de code
• Ajouter les informations manquantes

​

Nouveau contenu

• Tutoriels et guides
• Démarrages rapides pour nouvelles fonctionnalités
• Documentation de l’API
• Exemples de code et extraits
• Exemples de composants

​

Améliorations techniques

• Améliorations des composants
• Améliorations de la mise en forme
• Scripts d’automatisation
• Outils de documentation

​

Traductions

• Aidez à traduire le contenu (lorsque le support multilingue sera prêt)
• Améliorer les traductions existantes

​

Guide de la structure des fichiers

​

Où modifier différents types de contenu

​

Organisation de la section

v2/
├── home/                 # Home tab
│   ├── mission-control.mdx
│   ├── introduction/
│   └── project-showcase/
├── about/             # About tab
│   ├── about-portal.mdx
│   └── core-concepts/
├── developers/            # Developers tab
│   ├── building-on-livepeer/
│   ├── guides-and-resources/
│   └── builder-opportunities/
├── gateways/          # Gateways tab
│   ├── gateway-portal.mdx
│   ├── run/
│   └── build/
├── orchestrators/     # Orchestrators tab
│   ├── orchestrator-portal.mdx
│   └── run/
├── delegators/        # Delegators tab
│   └── delegator-portal.mdx
└── resources/         # Resources tab
    ├── resources-portal.mdx
    └── documentation-guide/

​

Ressources pour les contributeurs

​

Résumé du processus de contribution

​

Pour de petites modifications (fautes de frappe, liens cassés)

1. Fork et création d’une branche
2. Apporter la correction
3. Tester localement
4. Soumettre une PR
5. Traiter les retours

​

Pour les modifications de Medium (Mises à jour de contenu, exemples)

1. Ouvrir un problème pour en discuter (optionnel mais recommandé)
2. Forker et créer une branche
3. Apporter des modifications
4. Tester soigneusement
5. Soumettre une PR avec une description claire
6. Itérer en fonction des retours

​

Pour les grandes modifications (nouveaux guides, restructurations majeures)

1. Toujours en discuter en premier — Ouvrir un problème ou une discussion
2. Obtenir un retour et une approbation avant de commencer
3. Créer un plan détaillé
4. Forker et créer une branche
5. Travailler de manière incrémentale (considérer un PR brouillon)
6. Soumettre un PR avec une description complète
7. Itérer en fonction des retours nombreux

​

Reconnaissance

​

Des questions ?

• Consultez le Guide de documentation pour la structure et les conventions
• Consultez leGuide de style pour les directives de style
• Vérifiez leBibliothèque de composants pour l’utilisation de composants
• ExaminerCODEOWNERS pour voir qui examine quoi
• Ouvrir un problème GitHub ou une discussion
• Demandez dans la communauté Discord Livepeer

​

Proposition de contribution non technique

​

Options actuelles

1. Éditeur Web GitHub — Éditez les fichiers directement dans le navigateur
2. Formulaires de feedback — Soumettez des suggestions via des formulaires
3. Signalement des problèmes — Ouvrez des problèmes GitHub avec des suggestions de contenu

​

Flux de travail proposés

​

Option 1 : Mintlify Intégration de l’éditeur Web

1. Cliquez sur le bouton “Éditer cette page” sur n’importe quelle page de documentation
2. Ouvre l’éditeur web de Mintlify (nécessite une authentification)
3. Apportez des modifications en mode visuel ou en mode markdown
4. Soumettre les modifications qui créent automatiquement un PR GitHub

• Mintlify accès à l’éditeur web
• Authentification GitHub
• Création automatique du PR

​

Option 2 : Système de soumission par formulaire

1. L’utilisateur remplit le formulaire avec :
   • URL de la page ou section
   • Type de modification (faute de frappe, clarification, nouveau contenu)
   • Texte actuel (si applicable)
   • Texte proposé
   • Raison de la modification
2. Soumission du formulaire crée un problème GitHub
3. Le mainteneur examine et soit :
   • Applique le changement
   • Convertit en modèle de PR pour l’utilisateur
   • Demande plus d’informations

• Création de formulaire (Google Forms, Typeform ou personnalisé)
• Intégration de l’API GitHub
• Automatisation du modèle de problème

​

Option 3 : Bouton « Éditer cette page » avec un modèle de demande de tirage

1. Cliquez sur le bouton “Modifier cette page”
2. Ouvre l’éditeur web de GitHub pour ce fichier
3. L’utilisateur apporte des modifications
4. GitHub demande de créer un PR avec le modèle
5. L’utilisateur remplit la description de la PR
6. La PR est créée pour révision

• Ajouter des boutons « Éditer cette page » sur toutes les pages
• Créer un modèle de PR
• Lier à l’éditeur web GitHub avec la bonne branche

​

Option 4 : Intégration avec un CMS externe

1. Les utilisateurs non techniques modifient le contenu dans un CMS
2. Les webhooks du CMS déclenchent GitHub Actions
3. Les modifications sont automatiquement validées et une PR est créée
4. Le mainteneur examine la PR

• Configuration et mise en place du CMS
• Workflow GitHub Actions
• Synchronisation du contenu
• Authentification et autorisations

​

Ordre de mise en œuvre recommandé

1. Phase 1 (Quick Win) : Ajouter des boutons “Editer cette page” qui redirigent vers l’éditeur web GitHub
2. Phase 2 (Effort moyen) : Créer un système de soumission basé sur un formulaire avec automatisation des problèmes GitHub
3. Phase 3 (À long terme) : Évaluer l’intégration d’un éditeur web Mintlify ou une solution CMS

​

Retour d’information bienvenu

• Ouvrir un problème GitHub avec votre suggestion
• Discuter dans le Discord Livepeer
• Contacter l’équipe de documentation