À propos du nouveau rôle des sous-admins

Au cours des derniers mois, nous avons vu Discourse implémenter des améliorations et de nouvelles fonctionnalités dans le panneau d’administration. Comme pour tous les changements majeurs, cela a suscité des retours aussi bien positifs que négatifs.

Je pense que nous apprécions tous l’UI/UX de la nouvelle interface, et si nous constatons des écarts, c’est parce que nous utilisons nos forums de différentes manières.

Je suis sur le point de relancer ma communauté, et en analysant les diverses options disponibles dans mon panneau d’administration, je me rends compte d’avoir besoin d’un « sous-administrateur » qui devrait avoir accès à des fonctionnalités spécifiques — mais pas à l’ensemble des options offertes par /admin.

Les modérateurs et les TL3/TL4 gèrent le contenu et la communauté, tandis que les outils dont ce « sous-administrateur » disposerait sont plus larges et ont un impact sur la gestion interne de Discourse.

Cette liste est un brouillon succinct et n’est pas exhaustive. Elle donnerait une idée générale des points à discuter.

Autorisations de sous-administrateur permises :

  • Accès aux modèles de sentiment/émotion.
  • Mise à jour des traductions (textes) pour des traductions personnalisées qui s’adaptent mieux au jargon de la communauté.
  • Utilisateurs, groupes, badges, fonctionnalités à venir.
  • Liens permanents, mots spéciaux, intégrations (embeds).
  • Statistiques, modération, revue, et autres fonctionnalités qui ne nuiraient pas au site si elles étaient gérées par un sous-administrateur de confiance.
  • Configuration des plugins (peut-être sélectionnable depuis une liste pour éviter les plus sensibles).

Autorisations NON accordées au « sous-administrateur » :

  • Accès à toutes les options d’administration.
  • Mise à jour de l’instance Discourse.
  • Ajout ou suppression de composants de thème.
  • Accès à des paramètres spécifiques liés aux e-mails, à la sécurité, à la connexion des utilisateurs, etc.
  • Accès aux clés API, aux webhooks et à toute information sensible du site.

Cette nouvelle permission d’étendue (scoped) dans la section d’administration devrait être liée à deux panneaux d’administration distincts, basés sur les fonctions que chaque groupe d’administrateurs fournit.

Ainsi, nous aurions, d’une part (i) un tableau de bord technique, et d’autre part (ii) un tableau de bord fonctionnel, applicable aux PM, CM et rôles similaires dans différentes organisations, à leur discrétion.

La conception modulaire actuelle du panneau d’administration permettrait aux administrateurs principaux de choisir entre les différentes options, au cas où ils souhaiteraient également rester informés de ce qui se passe au niveau fonctionnel de la gestion de la communauté.

Je sais que cela pourrait prendre du temps, et ce n’est peut-être pas quelque chose que l’équipe souhaite aborder immédiatement, mais je pense qu’il serait excellent de commencer à en discuter avec la communauté Meta afin qu’elle puisse lire nos réflexions sur le sujet.

Dans mon cas particulier, dans une communauté de niche qui manque de structure organisationnelle (au-delà de ce qui émerge naturellement), je ne peux actuellement pas accorder certains privilèges d’accès, car confier l’ensemble du panneau d’administration ne serait pas bénéfique pour ce que nous faisons actuellement.

Cela me lie littéralement à toute la gestion de Discourse, alors que je pourrais déléguer une grande partie des tâches à l’équipe formée naturellement — puisque ce sont des personnes en qui j’ai confiance — mais elles n’ont pas encore l’expérience nécessaire pour que je délègue simplement ou leur accède à tout.

Vos avis ?