Así que no hablamos del despliegue de la instancia con la base de datos, etc.
¿Existe algún patrón para mantener una instancia utilizando algún formato declarativo? Categorías, etiquetas, políticas, etc. Estaba pensando que sería bueno que nuestros usuarios técnicos recomendaran cambios a través de PR en lugar de hilos de temas y cumplimiento manual, pero no vi ningún plugin u otra herramienta “as code” centrada en la configuración organizacional de Discourse.
Creo que la expectativa es que los sitios utilicen la categoría predeterminada Site feedback para esto. Su descripción es: “Discusión sobre este sitio, su organización, cómo funciona y cómo podemos mejorarlo”.
Esa es una idea interesante. ¿Qué beneficio tendría sobre simplemente hacer que los usuarios sugieran cambios en temas regulares? ¿El objetivo es tener una forma de hacer un seguimiento de los cambios que se han realizado en la configuración del sitio a lo largo del tiempo?
La configuración del sitio, las categorías, las etiquetas, las políticas, etc., se pueden configurar con la API de Discourse. Sería posible tener un script que gestione la configuración de su sitio a través de la API en un repositorio git. El script podría ejecutarse cuando se acepte un PR en el repositorio. Desde mi punto de vista, esto sería más difícil que realizar cambios manuales en la configuración del sitio a través de la interfaz de usuario.
10-4 en la Categoría. Por ahora, estaba recopilando información sobre un patrón existente. Para mí, se trata de lograr la participación de la comunidad al estilo gitops, así que me quedé con este, pero puedo pasarlo al otro si ayuda.
Y sí, usamos un poco de configuración como código para muchas cosas, por lo que se obtiene el control de revisiones limpio, la reversión determinista, la revisión clara de cambios, etc. Los cambios basados en GUI no están mal (y es lo que hacemos hoy a través de ciclos de retroalimentación de la comunidad), pero es una operación manual y el contexto de la decisión puede perderse con el tiempo. Y las construcciones de la organización existen en el medio entre la infraestructura y el diálogo real, por lo que no es una cuestión de implementación o rehidratación.
Y sí, los desencadenadores basados en PR (o incluso un Issue) pueden iniciar un runbook que determina el cambio propuesto y realiza la operación. Realizar el análisis de diferencias y el linting puede ser difícil, por eso estaba investigando para ver si alguien ya lo había intentado. La solicitud definitivamente está en el campo de lo “agradable de tener” y solo podría resonar con cierta demografía.
A mí (y estoy bastante seguro de que a nuestra comunidad de lenguajes de programación) nos encantaría esta capacidad. En particular, me gustaría poder administrar temas, componentes y textos del sitio en un repositorio de GitHub donde la gente pueda enviar fácilmente solicitudes de extracción (pull requests). La configuración general del sitio también estaría bien, pero son esas tres cosas las que son más difíciles de mantener en una interfaz web.
Si esto no es posible hoy —y no creo que lo sea, al menos no para una instancia de pago/alojada—, ¿podría esto ser reclasificado como una solicitud de característica?
Inmediatamente después de escribir eso, pensé en verificar la interfaz de usuario. Parece que esto es posible, ¡al menos para crear/importar un tema desde un repositorio de git! ¿Cómo funciona esto para las actualizaciones? ¿Puede extraer nuevos commits? Encontré Installing a theme from a private Git repository, pero eso no discute la actualización.
¿Es posible convertir un tema o componente existente para que rastree un repositorio de git?
Puedes exportar un tema, subirlo a un repositorio e instalarlo.
Todos los temas remotos tienen una sección en la parte superior donde puedes decidir si deseas que se actualice automáticamente cuando Discourse se actualice. Además, hay un trabajo en segundo plano que verifica si hay una versión más reciente disponible, y también puedes verificar manualmente las nuevas actualizaciones. Cuando hay una nueva versión disponible, el botón ofrece actualizar el componente.
También puedes encontrar esa información en la guía sobre Installing a theme or theme component.
En caso de que aún no lo hayas encontrado, también hay un tutorial sobre desarrollo de temas
¡Genial, gracias @Moin! Eso cubre dos grandes fuentes de personalización de nuestro sitio.
Aún me gustaría mucho usar git para administrar los Textos del Sitio, ya que muchos de ellos (como las guías, las preguntas frecuentes y demás) son extensos, no triviales y pueden ser de código abierto para la opinión y revisión de la comunidad.
Sería bueno tener los otros ajustes del sitio, pero definitivamente no es tan crucial.
Normalmente se basan en un tema en la categoría del personal. Creo que puedes moverlos a una categoría diferente y hacer que la publicación sea una wiki. Luego, tus miembros pueden editarlos.
También puedes usar la configuración del sitio FAQ URL, Privacy policy URL y ToS URL y alojarlos en otro lugar.
Sí, pero la configuración de URL de preguntas frecuentes (FAQ URL) tiene otros comportamientos que hacen que su uso sea muy contraproducente para este propósito.
Solo para señalar que está claro que ya es posible administrar contenido en el control de código fuente, échale un vistazo a este tema, se mantiene en GitHub:
en la parte inferior:
aunque no estoy seguro de si esta funcionalidad ya ha sido lanzada o anunciada (o si está prevista)
He empezado a experimentar con una acción de GitHub que envía actualizaciones a la sección site_texts del panel de administración a través de la API. Por el momento es bastante rudimentaria (y falla con valores grandes con un 422 por alguna razón), pero es prometedora.
Definitivamente necesita más trabajo.
