Sobre el nuevo rol de subadministradores

En los últimos meses, hemos visto cómo Discourse ha implementado mejoras y nuevas funciones en el panel de administración. Como todos los cambios importantes, ha recibido tanto comentarios positivos como negativos.

Creo que todos valoramos la interfaz y la experiencia de usuario (UI/UX) de la nueva interfaz, y si encontramos alguna discrepancia, se debe a que utilizamos nuestros foros de diferentes maneras.

Estoy a punto de relanzar mi comunidad, y al analizar las diversas opciones disponibles en mi panel de administración, me doy cuenta de que necesito un “subadministrador” que tenga acceso a funciones específicas, pero no a la totalidad de las opciones ofrecidas por /admin.

Los moderadores y los TL3/TL4 se encargan del contenido y de la comunidad, pero las herramientas que tendría disponibles este “subadministrador” son más amplias y tienen un impacto en la gestión interna de Discourse.

Esta lista es un borrador breve y no es exhaustiva. Daría una idea general de lo que necesita ser discutido.

Permisos de subadministrador permitidos:

  • Acceso a modelos de sentimiento/emoción.
  • Actualización de traducciones (textos) para traducciones personalizadas que se ajusten mejor al argot de la comunidad.
  • Usuarios, grupos, insignias, funciones próximas.
  • Enlaces permanentes, palabras especiales, incrustaciones (embeds).
  • Estadísticas, moderación, revisión y otras funciones que no dañarían el sitio si fueran manejadas por un subadministrador de confianza.
  • Configuración de plugins (quizás seleccionables desde una lista para evitar los más sensibles).

Permisos NO otorgados al “subadministrador”:

  • Acceso a todas las opciones de administración.
  • Actualización de la instancia de Discourse.
  • Adición o eliminación de componentes de tema.
  • Acceso a ajustes específicos relacionados con correos electrónicos, seguridad, inicio de sesión de usuarios, etc.
  • Acceso a claves API, webhooks y cualquier información sensible del sitio.

Este nuevo permiso con alcance limitado en la sección de administración debería estar vinculado a dos paneles de administración separados, basados en las funciones que cada grupo de administradores proporciona.

Así, tendríamos, por un lado, (i) un panel técnico, y por el otro, (ii) un panel funcional, aplicable a gerentes de proyecto (PMs), gerentes de comunidad (CMs) y roles similares en diferentes organizaciones, a su discreción.

El diseño modular actual del panel de administración permitiría a los administradores principales elegir entre las diferentes opciones, en caso de que también deseen estar al día sobre lo que sucede a nivel funcional en la gestión de la comunidad.

Sé que esto podría llevar tiempo y que quizás no sea algo que el equipo quiera abordar de inmediato, pero creo que sería genial comenzar a discutir esto con la comunidad de Meta para que puedan leer nuestras opiniones al respecto.

En mi caso particular, en una comunidad de nicho que carece de una estructura organizativa (más allá de la que surge de forma natural), actualmente no puedo otorgar ciertos privilegios de acceso porque entregar todo el panel de administración no sería beneficioso para lo que hacemos en este momento.

Esto me mantiene literalmente atado a toda la gestión de Discourse, aunque podría delegar una gran parte de las tareas al equipo formado de manera natural —ya que son personas de mi confianza—, pero aún no tienen la experiencia necesaria para que simplemente delegue o les permita acceso a todo.

¿Qué opinan?