Contribuir a las documentaciones

​

Proporcionar comentarios

​

En cualquier página

• Me gusta/No me gusta — Retroalimentación rápida sobre si la página fue útil
• Comentarios — Comparte comentarios, sugerencias o preguntas específicas
• Reporte de problemas — Informa errores, información obsoleta o enlaces rotos

​

Canales de retroalimentación general

• GitHub Issues — Abrir un problema en elLivepeer repositorio de documentación
• Discord — Compartir comentarios en el Discord de la comunidad Livepeer
• Correo electrónico — Contactar directamente al equipo de documentación

​

Contribuir a las Documentaciones

​

Contribuciones No Técnicas

​

Opción 1: Formulario de Comentarios

​

Opción 2: Sugerencias de contenido

• Identificar áreas que necesitan aclaración
• Sugerir nuevos temas o guías
• Reportar información obsoleta
• Compartir casos de uso o ejemplos

​

Contribuciones técnicas (Git y Markdown)

​

Flujo de Trabajo de Pull Request

​

Guía Paso a Paso

​

1. Fork del Repositorio

1. Navega agithub.com/livepeer/docs
2. Haz clic en el botón “Fork” en la esquina superior derecha
3. Esto crea una copia de tu repositorio

​

2. Clonar tu fork

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

​

3. Configurar el seguimiento remoto

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

# Verify remotes
git remote -v

​

4. Crear una rama

# 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/prefijo para cambios en la documentación
• Use nombres descriptivos: docs/fix-typo-quickstart-guide
• Use kebab-case (minúsculas con guiones)

​

5. Instalar ganchos de pre-commit

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

• Verificar si hay ThemeData uso
• Advertir sobre colores hexadecimales codificados
• Validar la sintaxis de MDX, JSON y JavaScript
• Comprobar las importaciones relativas
• Verificar las rutas de importación absolutas

​

6. Realiza Tus Cambios

• Páginas principales de la documentación: v2/pages/ (organizado por sección)
• Componentes: snippets/components/
• Archivos de datos: snippets/data/
• Activos: 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

• Use kebab-case para los nombres de archivos: quickstart-guide.mdx
• Use nombres descriptivos que reflejen el contenido
• Siga la estructura existente en cada sección

​

7. Probar localmente

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

# Run the development server
mint dev

• ✅ Las páginas se renderizan correctamente
• ✅ No hay errores en la consola
• ✅ Los enlaces funcionan correctamente
• ✅ Los componentes se muestran correctamente
• ✅ Ambos modos (claro y oscuro) funcionan
• ✅ Responsividad en dispositivos móviles

​

8. Confirma Tus Cambios

# Stage your changes
git add .

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

• Usa prefijos: docs:, fix:, feat:, chore:
• Sé descriptivo: “docs: agregar ejemplo de autenticación de API”
• Referencia problemas: “docs: actualizar configuración de gateway (fixes #123)”

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

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

​

9. Subir a su bifurcación

git push origin docs/your-branch-name

​

10. Crear una solicitud de extracción

1. Navegue agithub.com/livepeer/docs
2. Deberías ver una banda que sugiere crear una PR desde tu último envío
3. Haga clic en “Comparar y crear solicitud de extracción”
4. Complete la plantilla de la solicitud de extracción:
   • **Título:**Título claro y descriptivo
   • **Descripción:**Explica qué y por qué cambiaste
   • **Problemas relacionados:**Enlace a cualquier problema relacionado
   • Tipo: Marcar como cambio de documentación
   • **Prueba:**Describir cómo se probó

## 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. Atender los comentarios de revisión

• Responder a comentarios
• Realizar los cambios solicitados
• Enviar actualizaciones a la misma rama (aparecerán en la PR automáticamente)
• Marcar las conversaciones como resueltas cuando se terminen

​

12. Fusionar y limpiar

• Elimina tu rama localmente: git branch -d docs/your-branch-name
• Elimina tu rama en GitHub (opción disponible después de fusionar)
• Actualiza tu fork: git checkout docs-v2-preview && git pull upstream docs-v2-preview

​

Configuración de desarrollo

​

Requisitos previos

• Node.js (se recomienda v18 o superior)
• Git
• cuenta de GitHub

​

Instalación

# 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

​

Ejecutar localmente

# Start development server
mint dev

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

​

Estructura del proyecto

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

​

Directrices de contribución

​

Guía de estilo

• ✅ Use Propiedades personalizadas de CSS (var(--accent)) solo
• ❌ Nunca uses ThemeData o definir colores directamente
• ✅ Usar importaciones absolutas: /snippets/components/...
• ❌ No usar importaciones relativas para fragmentos
• ✅ Probar en modos claro y oscuro

​

Uso de componentes

• Usar componentes de la Biblioteca de componentes
• Consulte la documentación del componente antes de crear nuevos componentes
• Siga los patrones y convenciones existentes

​

Directrices de contenido

• Sé claro y conciso — Escribe para tu audiencia
• Usar ejemplos — Muestra, no solo cuentes
• Manténlo actualizado — Elimina la información obsoleta
• Enlázalo adecuadamente — Usa enlaces internos a contenido relacionado
• Añadir palabras clave — Ayuda con la descubribilidad

​

Ejemplos de código

• Usar resaltado de sintaxis adecuado
• Incluir ejemplos completos y ejecutables cuando sea posible
• Explicar qué hace el código
• Mostrar salida esperada cuando sea relevante

​

Requisitos de prueba

• Todas las páginas se renderizan sin errores
• No hay errores en la consola del navegador
• Los enlaces funcionan correctamente
• Los componentes se muestran correctamente
• Funciona en ambos modos (claro y oscuro)
• Responsivo en dispositivos móviles
• Las ganchos de pre-commit pasan

​

Proceso de revisión

​

¿Quién revisa qué

• Sección de desarrolladores: Equipo de relaciones con desarrolladores
• **Sección de puertas de enlace:**Equipo de puertas de enlace
• **Sección de orquestadores:**Equipo de orquestadores
• **Sección de delegadores:**Equipo de delegadores
• **Sección de recursos:**Equipo de documentación
• **General/Cortes transversales:**Equipo de documentación

​

Cronograma de revisión

• Cambios pequeños (errores de ortografía, enlaces rotos): Normalmente revisado en 24 horas
• Cambios en Medium (actualizaciones de contenido, ejemplos): 48-72 horas
• Cambios grandes (nuevos tutoriales, reestructuración importante): Puede tomar más tiempo, discutir en el problema primero

​

Criterios de revisión

• ✅ Precisión y corrección
• ✅ Cumplimiento de la guía de estilo
• ✅ Uso adecuado de los componentes
• ✅ Enlaces y ejemplos funcionales
• ✅ Tono y claridad adecuados
• ✅ SEO y visibilidad

​

Atención al feedback

• Responder a todos los comentarios
• Realizar los cambios solicitados o explicar por qué no se hacen
• Enviar actualizaciones a la misma rama
• Marcar las conversaciones como resueltas
• Solicitar una revisión nuevamente cuando esté listo

​

¿Qué contribuir

​

Mejoras en el contenido

• Corregir errores de ortografía y gramática
• Clarificar explicaciones confusas
• Actualizar información obsoleta
• Mejorar ejemplos de código
• Añadir información faltante

​

Nuevo contenido

• Tutoriales y guías
• Guías de inicio rápido para nuevas funciones
• Documentación de la API
• Ejemplos y fragmentos de código
• Ejemplos de componentes

​

Mejoras técnicas

• Mejoras de componentes
• Mejoras en el diseño
• Scripts de automatización
• Herramientas de documentación

​

Traducciones

• Ayuda para traducir contenido (cuando el soporte multilingüe esté listo)
• Mejorar traducciones existentes

​

Guía de estructura de archivos

​

Dónde editar diferentes tipos de contenido

​

Organización de la sección

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/

​

Recursos para colaboradores

​

Resumen del flujo de contribución

​

Para cambios pequeños (errores de ortografía, enlaces rotos)

1. Fork y crear rama
2. Realizar la corrección
3. Probar localmente
4. Enviar PR
5. Atender cualquier comentario

​

Para cambios en Medium (actualizaciones de contenido, ejemplos)

1. Abrir un problema para discutir (opcional pero recomendado)
2. Fork y crear rama
3. Hacer cambios
4. Probar exhaustivamente
5. Enviar PR con una descripción clara
6. Iterar según los comentarios

​

Para Cambios Grandes (Nuevos Guías, Reestructuración Mayor)

1. Siempre discutir primero — Abrir un problema o discusión
2. Obtener retroalimentación y aprobación antes de comenzar
3. Crear un plan detallado
4. Fork y crear una rama
5. Trabajar de forma incremental (considerar PR de borrador)
6. Enviar PR con una descripción completa
7. Iterar basado en comentarios extensos

​

Reconocimiento

​

¿Preguntas?

• Consulta laGuía de Documentación para estructura y convenciones
• Revisa la Guía de Estilo para pautas de estilo
• Consulta la Biblioteca de componentespara el uso de componentes
• Revisar CODEOWNERS para ver quién revisa qué
• Abrir un problema en GitHub o una discusión
• Pregunta en la comunidad Discord de Livepeer

​

Propuesta de Contribución No Técnica

​

Opciones Actuales

1. Editor Web de GitHub — Edite archivos directamente en el navegador
2. Formularios de retroalimentación — Envíe sugerencias a través de formularios
3. Informes de problemas — Abra problemas en GitHub con sugerencias de contenido

​

Flujos de trabajo propuestos

​

Opción 1: Integración del editor web Mintlify

1. Haz clic en el botón “Editar esta página” en cualquier página de documentación
2. Abre el editor web de Mintlify (requiere autenticación)
3. Realiza ediciones en modo visual o markdown
4. Envía los cambios que crean automáticamente un PR de GitHub

• Mintlify acceso al editor web
• Autenticación en GitHub
• Creación automática de PR

​

Opción 2: Sistema de envío basado en formulario

1. El usuario completa el formulario con:
   • URL de página o sección
   • Tipo de cambio (error de ortografía, aclaración, nuevo contenido)
   • Texto actual (si aplica)
   • Texto propuesto
   • Razón del cambio
2. El envío del formulario crea un problema en GitHub
3. El mantenedor revisa y realiza:
   • Implementa el cambio
   • Convierte a plantilla de PR para el usuario
   • Solicita más información

• Creación de formulario (Google Forms, Typeform o personalizado)
• Integración de la API de GitHub
• Automatización de plantillas de problemas

​

Opción 3: Botón “Editar Esta Página” con plantilla de PR

1. Haz clic en el botón “Editar esta página”
2. Abre el editor web de GitHub para ese archivo
3. El usuario realiza los cambios
4. GitHub solicita crear una PR con la plantilla
5. El usuario completa la descripción del PR
6. Se crea el PR para revisión

• Agregar botones de “Editar esta página” en todas las páginas
• Crear plantilla de PR
• Vincular con el editor web de GitHub con la rama correcta

​

Opción 4: Integración con CMS externo

1. Los usuarios no técnicos editan el contenido en CMS
2. Los webhooks de CMS activan GitHub Actions
3. Los cambios se comprometen y se crean PR automáticamente
4. El mantenedor revisa el PR

• Configuración y configuración de CMS
• flujo de trabajo de GitHub Actions
• sincronización de contenido
• Autenticación y permisos

​

Orden recomendado para la implementación

1. Fase 1 (Ganancia rápida): Agregar botones “Editar esta página” que enlacen al editor web de GitHub
2. Fase 2 (Esfuerzo moderado): Crear un sistema de envío basado en formularios con automatización de problemas de GitHub
3. Fase 3 (A largo plazo): Evaluar la integración del editor web Mintlify o una solución de CMS

​

¡Bienvenido el feedback

• Abre un problema en GitHub con tu sugerencia
• Discute en el Discord de Livepeer
• Contacta al equipo de documentación