Sitio del ecosistema de plugins
Muestra un ecosistema de plugins con páginas de detalle estructuradas, notas de versión y guías de instalación.
Un directorio de plugins es donde se gana o se pierde la confianza. Las personas visitantes no buscan adjetivos: quieren saber qué hace un plugin, quién lo mantiene, si está listo para producción, cómo se instala y cómo se comporta dentro de un stack real de EmDash. Un sitio público estructurado convierte esas respuestas en páginas consistentes en lugar de fragmentos dispersos de README.
Qué debe demostrar cada página de plugin
Empieza por resultados: el problema que resuelve, los entornos que soporta y la huella operativa (Workers, D1, APIs externas). Continúa con compatibilidad, versionado y licencia. Muestra enlaces al código fuente, descargas y documentación más profunda. Si algo está en beta, dilo de forma explícita y explica qué significa “beta” para datos y disponibilidad.
Pasos concretos de despliegue
-
Define una única plantilla de página. Los campos estándar pueden incluir estado, categoría, versión, modelo de precio, compatibilidad, enlace al repositorio y changelog. La consistencia ayuda a comparar opciones rápidamente.
-
Publica guías de instalación que coincidan con la realidad. Prioriza comandos y fragmentos de configuración que funcionen con la estructura actual del repositorio; por ejemplo, referenciar
packages/plugins/<name>en el monorepo de EmDash cuando esa sea la fuente de verdad. -
Publica notas de versión en cada cambio relevante. Incluso una lista breve de viñetas es mejor que el silencio. Enlaza a vistas de comparación de GitHub o a releases etiquetados cuando sea posible.
-
Añade señales de confianza. El nombre del mantenedor, el canal de soporte y las expectativas de seguridad deben estar en la página, no solo en chat. Para plugins que llaman APIs de terceros, documenta secretos requeridos y límites de tasa.
-
Cruza enlaces con casos de uso. Conecta plugins con los escenarios que habilitan: Forms para captación de leads, Webhook Notifier para automatización, Audit Log para equipos con múltiples editores.
Ejemplo: evaluar un plugin nuevo para el listado
Antes de publicar la página, recorre esta lista de verificación: ¿la descripción de una línea coincide con lo que realmente exporta el código? ¿las capturas o diagramas son precisos? ¿la licencia es correcta? ¿una persona nueva puede instalarlo sin conocimiento interno? Si alguna respuesta es “no”, corrige ese hueco antes de promocionar el plugin.
Cadencia operativa
Mensualmente: revisa issues abiertos y actualiza campos de estado. Trimestralmente: depreca listados abandonados o márcalos como “unmaintained” con notas de migración. Tras grandes releases de EmDash: vuelve a probar los plugins principales y actualiza las cadenas de compatibilidad.
Resultado
Los equipos creadores descubren plugins más rápido, los adoptan con menos sorpresas y tratan tu ecosistema como infraestructura seria, no como un folleto.