TL4s publicando en temas archivados

Soporte
1

¿Es esto un error o una característica intencional? Si es un comportamiento intencional, ¿cómo puedo restringirlo, si es posible?

He cerrado varios hilos porque ya no son oportunos. He estado haciendo actualizaciones regulares sobre nuestra transición del software antiguo a Discourse. El problema es que nuestros TL4 (representantes locales) siguen publicando en ellos de todos modos. Sí, puedo eliminar y redirigir (que es lo que he estado haciendo). Así que pensé: “Bien, los archivos deberían ser inalterables, así que vamos allá”.

Así que archivé la publicación.

¡AÚN pueden publicar allí! Mi comprensión de los archivos es que deberían impedir publicaciones, “me gusta”, etc. Sin embargo, para los TL4, no funciona así. Tiene sentido que el personal pueda actualizar temas archivados, pero los TL4 no son personal.

Entonces, ¿cómo demonios puedo bloquear realmente estas publicaciones para que la gente deje de actualizarlas? Eliminar el grupo TL4 no es realmente una opción (el grupo en cuestión lo necesita por varias razones). Gran parte de esto es educación, sí, pero todos sabemos lo bien que la gente lee y presta atención a las instrucciones. El punto de un archivo es bloquearlo, congelarlo en carbonita. Si la comunidad aún puede interactuar con él, no está archivado. No me preocupa que puedan desarchivarlo; eso está bien. Tiene sentido. Al menos deberían tener ese paso entre poder publicar y no poder hacerlo.

2

Vale, sí, finalmente lo encontré tras hacer algunas investigaciones. Sí, este es el comportamiento previsto.

Sin embargo, diré que esto hace que la función de archivo sea un poco extraña. Para mí, los archivos deberían ser exactamente eso… archivados. Si necesitas hacer un cambio, deberías tener que desarchivarlos para hacerlo. De lo contrario, no hay ninguna diferencia funcional entre cerrar y archivar, más allá de la posibilidad de dar me gusta a una publicación o no.

3

Hay cierta confusión en varias discusiones sobre temas archivados.

Quizás los siguientes puntos puedan aclarar el espacio conceptual y cómo encaja la función de archivado de Discourse en él:

1. La capacidad de editar archivos en Discourse está diseñada para niveles de confianza (TL) 4 y superiores. No es un error ni una omisión.

Contrasta esto con la declaración de 2015 sobre estar congelado en carbonita, que claramente no coincide con la realidad de la función de archivado de Discourse.

Es lamentable que esa publicación persista en cita tras cita. Suena y parece bien, pero genera una expectativa poco realista de que nada cambiará nunca en un archivo. Eso nunca ha sido así en el mundo real, donde la información de los elementos archivados siempre puede añadirse o modificarse.

2. En general, hay dos características clave de los archivos: almacenados y no publicados

  • Se conservan para la posteridad porque tienen algún valor deseado.
  • Se transfieren y almacenan en un estado “no publicado”.

Conceptualmente, existe una distinción clara entre usar bibliotecas para acceder a elementos publicados y usar archivos para acceder a elementos no publicados.

Esta distinción se está desdibujando en el uso real debido a que los archivos están aumentando su uso de catálogos electrónicos e imágenes digitales de los elementos. Esto significa que los elementos de archivo o sus reproducciones son cada vez más accesibles a través de los sistemas bibliotecarios.

La situación en Discourse es muy similar: los temas archivados siguen listados, pero no aparecen en todas las listas. Ocultar un tema lo hace más parecido a un elemento de archivo tradicional, requiriendo un esfuerzo adicional para encontrarlo en un silo segregado.

3. Interactuar con temas archivados en Discourse funciona de manera muy similar a como manejamos los elementos de archivo en la vida real.

Podemos acceder a la zona de archivo (sala, taquilla, estantería, carpeta, expediente, …) y podemos acceder a cualquier elemento para añadirlo, anotarlo o etiquetarlo, prestarlo y retirarlo, por ejemplo, para destruirlo.

Por lo tanto, no es normal en el mundo real desarchivar un elemento para realizar dichos cambios, excepto cuando se destruye o se elimina permanentemente de la colección.

He aquí la razón. En el mundo real, cambiar el estado implica un esfuerzo físico, por lo que no lo haríamos a menos que el cambio de estado sea permanente, por ejemplo: mover una caja del almacenamiento a otro edificio, eliminar la entrada del catálogo y actualizar los índices, o estampar la caja como retirada del archivo para que no se devuelva por error.

En el mundo digital es un esfuerzo mínimo cambiar el estado de un elemento de archivo. Es factible implementar esa lógica, pero disminuye la utilidad del término archivo.

4

El problema es que esta cita proviene de los desarrolladores y se menciona regularmente en la documentación de cómo hacer aquí. Si esto no refleja la realidad de la implementación, debe ocurrir una de dos cosas:

  1. La documentación debe actualizarse para que refleje claramente la realidad de la función activa.

  2. La función activa debe actualizarse para reflejar el diseño y la intención originales.

Así es como entiendo un archivo; para modificarlo, debes retirarlo físicamente del archivo. Sería lógico tener un comportamiento similar en formato digital.

El problema que yo tengo es que la diferencia funcional entre cerrado y archivado es tan mínima que resulta casi inútil. Cerrado o archivado; para mí, cerrado significa que no se permiten más comentarios. Archivado significa “ya no se puede cambiar” en comparación específicamente con cerrado.

Deslistar es una función completamente diferente, no relacionada con el archivo, y no es relevante aquí. Por eso es una función separada del archivo.

En mi caso, no quiero deslistar esas cosas malditas, solo quiero que la gente deje de responder a ellas. Tienen información histórica útil, pero ya no son relevantes para las quejas o la funcionalidad actual. Si solo quisiera que fueran accesibles mediante enlace, las deslistaría.

Esa es toda la razón de cerrar y, posteriormente, archivar.

En cuanto a las comparaciones con el mundo real: los archivos en la web, especialmente los de foros, siempre son de solo lectura. Se proporcionan con fines históricos, no para “actualizar esto cuando lo necesitemos”. Se consultan, pero no se actualizan. Por eso existen. Esta función, actualmente, no funciona como un archivo real. No se pretende agregar contenido a un archivo digital. Puedes agregar nuevos elementos al archivo, pero no se abren los existentes para realizar cambios. Si necesitas hacer eso, no deberían estar en el archivo porque están activos y son relevantes.

Si deseas algo que ya no sea relevante pero que aún sea actualizable, ciérralo. Que el estado de cerrado sea irrelevante para TL4 y superiores tiene sentido.

5

Esto no es un problema de tecnología; si tus usuarios de TL4 no respetan la solicitud de no responder a temas cerrados o archivados, probablemente no deberían ser TL4.

Por otro lado, si no les has pedido que no interactúen con esos temas, es un asunto totalmente diferente.

6

Un complemento podría resolver tu problema tecnológico: no permitir añadir o modificar publicaciones en temas archivados. Podría demostrar la popularidad de tus preferencias. Si se vuelve popular, quizás los cambios que deseas podrían incorporarse en Discourse.

La representación visual es incompleta. Prefiero centrarme en la funcionalidad real en lugar de en metáforas.

Hablé de cambiar el estado de archivado a no archivado, lo cual es una tarea mayor que modificar el elemento archivado en sí.

No es cierto. La archivación en Discourse elimina sustancialmente el tema de la interfaz de usuario. La vía principal para encontrar algunos temas son entonces los enlaces explícitos. Archivar es como un ocultamiento parcial para reducir las interacciones casuales:

El ocultamiento completa el proceso de eliminación de la lista, por lo que es relevante.

Técnicamente, la mayoría de los archivos en la web son “instantáneas” de la capa de presentación. Por eso también suelen ser de solo lectura, ya que no incorporan toda la entidad que representan. Son más como fotografías, como sugiere la palabra instantánea. Por lo general, carecen del código de programa y de la estructura de base de datos necesarios para permitir una mayor interacción con la entidad original.

Si nos centramos más específicamente en los archivos de foros (y blogs, correos electrónicos y otros tipos de medios), existen distintos niveles de interacción disponibles. No todos los archivos son de solo lectura y muchos pueden desarchivarse simplemente haciendo clic en restaurar/publicar. Cuanto más alejado esté el archivo del código central del foro y de su estructura de datos, más de solo lectura suele ser. Sé que algunos foros tienen problemas al desarchivar cuando las categorías originales ya no existen. La archivación en Discourse evita ese problema.