Presentamos Upcoming Changes, un sistema para gestionar nuevas funciones y cambios en la funcionalidad existente de tu comunidad

[lindsey (Lindsey Fogle)]

A medida que seguimos mejorando Discourse, hemos creado una nueva página de configuración de «Cambios futuros» para ayudar a los administradores a comprender qué cambios se avecinan en Discourse y permitirles gestionar cómo se implementan esos cambios en su comunidad. Creemos que este sistema nos ayudará a seguir mejorando Discourse de forma segura y transparente.

En este tema, explicaremos cómo funciona este nuevo sistema y cómo utilizarlo para introducir nuevas funciones y otros cambios de forma segura en su comunidad.

Resumen del funcionamiento de los cambios futuros

A medida que trabajamos en nuevas funciones u otros cambios, los añadiremos a la página de configuración de «Cambios futuros» en /admin/config/upcoming-changes. Cada cambio incluirá una descripción, el estado, un indicador de qué usuarios se ven afectados por él y para qué usuarios (si los hay) está activado en su comunidad.

Dependiendo del estado del cambio, podrá decidir si lo activa o desactiva para su comunidad, al menos temporalmente, ya que algunos cambios se activarán de forma permanente en el futuro.

Desactivar temporalmente un cambio le da tiempo para abordar cualquier personalización del sitio, proceso, etc., que se vea afectado, informar a su base de miembros sobre el cambio o delegar en ciertos grupos de miembros para las pruebas.

Análisis de un cambio futuro

Analicemos un cambio futuro y definamos la información que verá en cada sección.

1. Nombre y descripción

El nombre y la descripción le ofrecen una breve explicación del cambio y enlazan al tema de Meta relacionado para obtener información adicional y un lugar para recopilar comentarios.

2. Estado

El estado comunica su posición en el ciclo de desarrollo. El estado afecta directamente si el cambio es opt-in (es decir, desactivado por defecto, pero puede activarlo), opt-out (es decir, activado por defecto, pero puede desactivarlo) o forzado (es decir, activado y no puede desactivarlo).

Utilizamos los siguientes estados en Cambios futuros:

• Experimental: Un cambio potencial que está en fase temprana de desarrollo/pruebas y se espera que evolucione rápidamente, o puede eliminarse por completo si terminamos el experimento (en cuyo punto pasará al estado Inactivo; véase más abajo). Puede opt-in a cambios Experimental para probarlos.
• Alpha: Un cambio probado que es seguro de usar, aunque puede haber algunas actualizaciones menores en su diseño o funcionalidad. Puede opt-in a cambios Alpha para usarlos anticipadamente.
• Beta: Un cambio probado que es seguro de usar y es poco probable que cambie mucho antes de pasar al estado Estable o posiblemente Permanente.
  • Para la mayoría de los sitios en nuestro alojamiento y para los sitios autoalojados, los cambios Beta se activan automáticamente para todos (si no lo ha habilitado previamente), pero aún puede opt-out.
• Estable: Un cambio completado^[1], pero sigue siendo opt-out (es decir, los administradores pueden desactivarlo). Se advertirá a los administradores en su panel cuando hayan optado por no participar en un cambio Estable.
• Permanente: Un cambio que ha completado las pruebas y está forzado (es decir, los administradores no pueden desactivarlo). Los cambios permanentes ya no aparecerán en la lista de cambios futuros, en su lugar se mostrarán en la página /admin/whats-new.
• Inactivo: Un experimento abandonado. No puede opt-in.

A veces, los cambios avanzan linealmente por estos estados (es decir, comienzan en Experimental y terminan en Permanente), pero no siempre. Algunos cambios pueden introducirse en estado Alpha o Beta, y algunos terminarán en estado Estable. Los cambios que son del tipo «valor predeterminado de la configuración del sitio» no se moverán a Permanente, ya que solo están cambiando el valor predeterminado de una configuración existente.

No hay un tiempo establecido para cuánto tiempo le tomará a un cambio en particular avanzar de un estado a otro, pero se notificará a los administradores cuando:

• Esté disponible un nuevo cambio para probarlo
  • Estos se envían como máximo una vez por semana para evitar la fatiga de notificaciones. Si prefiere no recibir estas notificaciones, puede desactivarlas en /my/preferences/notifications
• Se haya habilitado automáticamente un cambio
• Cuando haya desactivado un cambio que pronto se forzará
  • Esto se mostrará como una advertencia en el panel de administración

3. Usuarios afectados

La etiqueta de usuarios afectados describe qué usuarios de su comunidad pueden ver o interactuar con el cambio de alguna manera. Para ponerlo simplemente: ¿quién podría notar este cambio? Hay varios tipos de usuarios afectados:

• Administradores: El cambio solo es visible para los administradores.
• Personal: El cambio solo es visible para los administradores y moderadores.
• Todos los miembros: El cambio es visible para todos los miembros de su sitio.
• Desarrolladores: En casos raros, un cambio solo será notable para aquellos que interactúan con el código en el núcleo, temas o plugins.

Tipo de impacto

Un subconjunto de usuarios afectados, y que no se muestra en la lista, es el tipo de impacto. El tipo de impacto describe cómo el cambio afectará a su comunidad en un sentido amplio:

• Función: El cambio introduce una nueva función o funcionalidad a su comunidad, o modifica la funcionalidad existente.
• Valor predeterminado de la configuración del sitio: El cambio modifica el valor predeterminado de una configuración del sitio existente. Los administradores que ya hayan cambiado la configuración de su antiguo valor predeterminado no se verán afectados. No se mostrará ninguna advertencia en el panel de administración para este cambio una vez que alcance el estado Estable.
• Otro: Cualquier otro cambio que no encaje en las categorías anteriores.

4. Habilitado para…

Este menú desplegable es donde usted, como administrador del sitio, puede controlar si y cómo introducir este cambio en su comunidad habilitándolo para:

• Nadie: Desactiva el cambio para todos en el sitio.
• Todos: Habilita el cambio para todos en el sitio, incluidos los usuarios anónimos. Cuando el cambio se activa automáticamente (típicamente en estado Beta), será para Todos.
• Solo personal: Habilita el cambio para el personal del sitio (es decir, administradores y moderadores).
• Grupos específicos: Habilita el cambio para el grupo(s) seleccionado(s).

Algunos cambios futuros pueden tener opciones «Habilitar para» restringidas. Las opciones disponibles en el menú desplegable «Habilitado para» están determinadas por la configuración del cambio. Por ejemplo, ciertos cambios podrían permitir solo las opciones Todos y Nadie, ya que las pruebas limitadas por grupo no serían factibles para el cambio.

---

Por ahora, hemos movido la mayoría de los cambios Experimental de /admin/config/experimental a Cambios futuros, y pronto comenzará a ver nuevas actualizaciones aquí. Esperamos con interés escuchar sobre el impacto que esto tenga en su comunidad, ¡y bienvenidas cualquier pregunta o comentario!

---

1. En la medida en que cualquier software esté completo! ↩︎

[NateDhaliwal]

Tengo curiosidad: ¿cómo controla el despliegue del cambio? ¿Se puede modificar después de que se introduzca la función? Gracias.

[merefield (Robert)]

¡Funcionalidades nativas de Feature Flags! Muy bien

Sería genial tener una API para plugins.

[Canapin (Coin-coin le Canapin)]

¡Esa es una característica muy esperada! ¡Gracias!

[darkpixlz (Pyx)]

Esto es genial, tener la capacidad de cambiar las banderas de esta manera es increíble para personas a la vanguardia como yo, especialmente al desarrollar un tema.

¿“Cambios próximos” es realmente el mejor nombre para esto? Por ejemplo, HomeAssistant usa “labs” (laboratorios) y muchas otras personas simplemente usan cosas como “experimentos”, que se sienten mejor que cambios próximos.

[lindsey (Lindsey Fogle)]

@NateDhaliwal

Tengo curiosidad: ¿cómo controla cómo se implementa el cambio?

Se le notificará sobre las nuevas funciones mientras se encuentren en un estado en el que pueda probarlas anticipadamente (opt-in) y desactivarlas temporalmente para solucionar cualquier problema causado por el cambio (opt-out). Si un cambio va a ser permanente (lo que significa que no puede desactivarlo) y actualmente lo ha desactivado, se lo haremos saber.

Esta sección lo describe con un poco más de detalle:

@lindsey

A veces, los cambios se moverán linealmente a través de estos estados (es decir, comenzarán en Experimental y terminarán en Permanent), pero no siempre. Algunos cambios pueden introducirse en estado Alpha o Beta, y algunos terminarán en estado Stable (si no se forzarán).

No hay un tiempo establecido sobre cuánto tardará un cambio en particular en progresar de un estado a otro, pero se notificará a los administradores cuando:

• Haya un nuevo cambio disponible para probar
• Se haya habilitado un cambio automáticamente
• Cuando haya desactivado un cambio que pronto se forzará

@darkpixlz

¿Es “cambios próximos” realmente el mejor nombre para esto?

Por ahora, solo está viendo cambios experimentales porque migramos esos desde el área de configuración a Cambios Próximos, pero en el futuro también habrá actualizaciones no experimentales aquí. Por lo tanto, “labs” no parece preciso para cómo estamos utilizando este sistema.

[martin (Martin Brennan)]

@merefield

Sería genial tener una API para complementos.

Los complementos ya pueden usar este sistema. El OP no entra en los detalles técnicos, pero no se necesita mucho para agregar un próximo cambio.

El resumen rápido es:

• Agregar una configuración del sitio que tenga hidden: true y client: true

• Agregar una descripción para la configuración en server.en.yml

• Opcionalmente, agregar una captura de pantalla a public/images/upcoming_changes/SETTING_NAME.png

• Agregar metadatos upcoming_change a la configuración, que se ve así:

# upcoming_change       - Metadatos adicionales con las siguientes opciones para mostrar en la página /admin/config/upcoming-changes:
#                          - status: experimental | alpha | beta | stable
#                          - impact: dos partes separadas por coma - feature|other , staff|admins|moderators|all_members|developers
#                          - learn_more_url: una url para más información

Sin embargo, la advertencia aquí es que realmente no hemos tenido la intención de que los desarrolladores de complementos de terceros utilicen este sistema, fue principalmente para nuestros propios fines. Quizás con el tiempo podamos pensar más en este caso de uso.

[noahl (Noah Lovell)]

¡Me encanta esto! Gracias

¿Sería posible tener un enlace/atajo a la configuración aplicable si es relevante? Por ejemplo, la pantalla de bienvenida personalizada tiene configuraciones adicionales que deben configurarse para que funcione (subir el SVG), pero tienes que ir activamente a buscarlas. Sería útil tenerlas junto a donde se está habilitando.

[martin (Martin Brennan)]

¡Sí, por supuesto! Estoy trabajando en ese cambio ahora, debería estar disponible en uno o dos días. Tomaré nota de implementar su sitio alojado para que reciba la actualización

Edición: ¡Hecho!

[sniper756]

Me gustaría preguntar, para una instalación de Discourse autogestionada, ¿cómo se muestran los “Próximos cambios” en el panel de administración?

@lindsey

[martin (Martin Brennan)]

Todavía tenemos esto oculto detrás de una configuración global del sitio enable_upcoming_changes, la cual está oculta, por lo que puedes habilitarla en la consola de rails de tu sitio con rails c. Eventualmente eliminaremos esto y ya no tendrás que hacerlo.

[sniper756]

De acuerdo, gracias, entonces esperaré~~~

[ToddZ]

No estoy seguro de si esto quedó claro: el elemento del menú para Próximos Cambios aún no está activo, pero …

reformulación:
Si aún no tienes el elemento del menú, puedes ver la sección Próximos Cambios yendo a [tu_foro]/admin/config/upcoming-changes

[martin (Martin Brennan)]

¿No debería estar ahí, no lo ves aquí?

¿Estás autoalojando? Si es así, también necesitarás configurar enable_upcoming_changes (que es una configuración oculta) a true. Planeamos eliminar esto en un futuro no muy lejano una vez que estemos completamente seguros de que el sistema es estable.

[Moin]

¿Hay alguna razón por la que la mayoría de las configuraciones del sitio para los próximos cambios estén ocultas, pero enable_auto_grid_images no lo esté?

[martin (Martin Brennan)]

@Moin

enable_auto_grid_images

No, solo fue una supervisión, solucionado aquí:

FIX: Hide enable_auto_grid_images site setting (#38046)

[ToddZ]

Sí, estoy autoalojando, como sniper756.
“aún no está en vivo” quizás no fue la mejor formulación; lo editaré.

[Moin]

Hoy estaba pensando que sería útil poder ordenar los cambios por estado: primero beta, luego alpha y finalmente experimental. Sé que puedo filtrar por ese criterio, pero me gusta ver toda la lista; simplemente encuentro los cambios más o menos interesantes según su estado.

[martin (Martin Brennan)]

Sí, tiene sentido. También he pensado en añadir una opción de ordenamiento según cuándo apareció el cambio en tu sitio… ¡añadiré ambas!

[khenmu (John Sweeney)]

¡Fantástica adición!

Gracias por esto.