Oui, je suis d’accord que l’incohérence dans les paramètres du site fait partie du problème. Mais corriger cela ne signifie pas nécessairement qu’il faut continuer à utiliser le groupe existant everyone pour les paramètres du site.
Je ne pense pas que l’argument de 2013 nous en apprenne beaucoup au-delà de la durée d’existence de everyone pour les permissions de catégorie. Beaucoup de choses ont changé dans Discourse depuis 2013 ; par exemple, de nombreux paramètres du site étaient basés sur le niveau de confiance, tandis qu’ils sont maintenant basés sur les groupes. Personne ne remet en question le fait que cela ait du sens dans ce contexte, et les permissions de catégorie ne sont pas modifiées par ce travail (du moins, pour le moment). Son ancienneté n’établit pas qu’il a un sens cohérent dans le reste de Discourse, ou que nous devrions le conserver indéfiniment.
Même si nous étions d’accord que chaque divergence par rapport au sens d’origine était une erreur, nous devrions toujours gérer le comportement réel de ces paramètres sur les sites existants. Nous ne pouvons pas changer en toute sécurité leur interprétation pour inclure les utilisateurs anonymes simplement parce que cela correspondrait mieux au comportement original des catégories. Comme je l’ai expliqué ci-dessus, maintenir un groupe universel avec un sens cohérent nécessiterait toujours d’auditer et de migrer ces utilisations. C’est une conception alternative, mais elle n’évite pas la partie la plus difficile de ce travail.
Concernant le point sur la RFC, avoir une RFC communautaire avant d’apporter des modifications de ce type serait lent et prohibitif, bien que les commentaires soient les bienvenus, c’est à cela que sert le système de changements à venir. Ce sujet a déjà conduit à plusieurs améliorations à partir des exemples de Moin, et j’ai reconnu les cas de thème/composant que j’avais manqués initialement et je les ai corrigés également.
Je suis heureux de continuer à travailler sur des problèmes concrets liés au changement, mais je vais quand même de l’avant avec les deux groupes explicites. Rendre l’accès public facile à sélectionner dans l’interface utilisateur semble une manière raisonnable de répondre au problème des clics supplémentaires, mais je ne pense pas que ce soit nécessaire à implémenter immédiatement.
De toute façon, j’ai encore beaucoup de travail suivi dans The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions pour cela, donc cela prendra encore un moment, tout comme les modifications liées au système de catégories, qui conserve everyone pour le moment. Les catégories sont susceptibles de passer à un système que nous appelons ACL, que kanban utilise déjà :
