Bonjour, ce n’est pas équivalent et nous avons donné de nombreux exemples ci-dessus.
Il serait équitable de faire une déclaration claire indiquant que vous ne reverserez pas cette option de toute façon, ou quelque chose de similaire.
Je pense que plusieurs, peut-être des dizaines, d’administrateurs/administrateurs de communauté attendent encore.
Cette tempête entière concerne les sites qui demandent certains niveaux de fidélité.
Ils veulent que la liste des derniers sujets ait « exactement » telle apparence, et que les utilisateurs finaux n’aient aucun contrôle sur la façon dont elles apparaissent « exactement » ainsi.
Dans le cas de @Heather_Dudley / @ClawdiaWolf, cela peut poser problème pour les utilisateurs finaux. Il y avait une suppression de toutes les catégories « régionales » de la page d’accueil, car il y avait 400 régions et cela devenait bruyant.
Mais qu’en est-il d’un utilisateur de Sydney ? Pourquoi cet utilisateur n’est-il pas autorisé à voir les sujets de Sydney sur la page d’accueil ?
Pour remédier à cela, nous permettons désormais aux sites de fonctionner dans un mode où les éléments sont désactivés par défaut et où les modérateurs peuvent opter pour des catégories « affichées par défaut ». Cela rend la maintenance bien plus facile à l’avenir. Lorsque vous ajoutez une catégorie, vous n’avez rien à faire, et les utilisateurs peuvent toujours suivre Sydney s’ils le souhaitent.
Je pense que cela va se solder par le fait que nous fournirons des hooks de plugin pour les personnes qui souhaitent une dictature stricte d’en haut concernant les sujets qui ne pourront jamais, jamais, jamais, jamais être affichés dans les listes des derniers sujets.
Cela signifie-t-il qu’il n’y a aucun moyen de réparer notre section en langue étrangère ?
Ces catégories sont actuellement masquées sur la page « Catégories », et les publications en langue étrangère apparaissent dans « Derniers », qui est censé être uniquement en anglais. Je ne sais pas si les gens ne reçoivent plus de notifications pour les sections en langue étrangère.
Même si je vais à la catégorie parente « Non-anglais » (qui semble ne pas être découvrable par les utilisateurs), une seule des sous-catégories linguistiques (Nederlands) y est répertoriée — les autres catégories linguistiques ont disparu.
Étrangement, si je publie dans l’une des catégories linguistiques, cette publication apparaît toujours dans /latest, même si la page de la catégorie elle-même a disparu.
Y a-t-il encore un moyen de garder les sujets hors de la page d’accueil sans les mettre en sourdine ?
Le seul problème que je vois pour le site que je consulte actuellement, c’est qu’il n’y a aucun moyen de savoir qu’il existe une catégorie française à réactiver, à moins de la trouver dans vos préférences ou, peut-être, d’avoir un sujet (ou un lien d’en-tête, ou similaire) qui pointe vers la catégorie française.
Désolé, je pense que je suis un peu confus quant à l’impact de ce changement. Auparavant, lorsque les utilisateurs accédaient à /categories, une liste de catégories en langues étrangères s’affichait. Aujourd’hui, ces catégories ont disparu et je ne sais pas comment les rétablir dans cette liste. Cependant, les publications de ces catégories ne devraient pas apparaître dans /latest, car « latest » est réservé aux publications en anglais.
Quelque chose semble étrange. Lorsque je me rends dans la catégorie parente (/c/non-english) avec un compte administrateur, je ne vois que la catégorie « Nederlands » (la dernière ajoutée aux catégories). Si je vais sur /categories avec un compte administrateur, les catégories Non-English n’y figurent pas.
Lorsque je me connecte avec un compte de test (TL0), je vois toutes les 9 catégories Non-English sur les pages /categories et /c/non-english.
Cependant, mon message de test dans une catégorie Non-English apparaît sur /latest, alors que cette page devrait être réservée à l’anglais uniquement.
Édition : tant l’administrateur que l’utilisateur TL0 voient le sujet défini sur « en veille » après avoir publié un message. Je ne vois pas l’option « silencieux ».
La mise en sourdine des catégories fait référence à un état par défaut ; tout sujet de cette catégorie peut toujours être suivi et surveillé par les utilisateurs qui modifient l’état par défaut de la catégorie.
Non, car la mise en sourdine continuera d’afficher certains sujets spécifiques dans /latest dès qu’un utilisateur interagit avec eux.
L’ancienne approche permettait aux administrateurs du site de créer des partitions là où ils le jugeaient nécessaire. La fonction de mise en sourdine existait déjà, mais comme le montrent les messages ci-dessus, elle est beaucoup plus désordonnée.
Là où il y avait autrefois « masquer cette catégorie dans /latest », nous aurons désormais :
un paramètre de catégorie pour la mise en sourdine
un paramètre utilisateur pour la mise en sourdine
un paramètre utilisateur pour la visibilité
Si vous souhaitez vraiment reproduire le comportement initial, nous aurions besoin d’un paramètre supplémentaire pour empêcher les publications des catégories mises en sourdine de réapparaître dans /latest, car, comme nous l’avons lu, certains administrateurs de site ont des cas d’usage où cela est avantageux.
Un projet sur lequel je travaille sera bientôt mis en pause à cause de ce problème. Le client souhaitait utiliser Discourse pour la collaboration interne, avec certaines catégories masquées car elles contenaient soit des discussions sur des titres encore non annoncés, soit des sujets « hors sujet ». Ils aimaient le comportement offert par « masquer de /latest », car même si le personnel participait à des sujets dans ces catégories, les titres de ces sujets ne seraient pas visibles sur / (qui était censé être /latest), ce qui les obligerait à rechercher activement ces catégories. Pour l’instant, je suggère à nouveau qu’ils utilisent une instance secondaire et séparée pour obtenir la même séparation.
État par défaut de la catégorie fait référence à l’état par défaut des sujets provenant d’une catégorie particulière, un état qui peut être modifié lorsqu’un utilisateur interagit avec eux. L’hypothèse sous-jacente à tout ce qui précède est que ce comportement est toujours souhaitable, mais en regardant les instances polyvalentes, il semble que ce ne soit pas le cas.
C’est quelque chose avec quoi je suis fondamentalement en désaccord. Si un utilisateur suit ou surveille explicitement un sujet, cela indique très clairement qu’il s’intéresse réellement au sujet et souhaite le voir dans « Derniers ». S’il ne veut pas le voir dans « Derniers », il peut toujours le repasser en mode normal, non ?
Je ne suis pas sûr de comprendre.
Tout ce que je propose ici, c’est une option utilisateur pour :
« Je ne me soucie vraiment, vraiment, jamais des catégories muettes et je ne veux jamais les voir », aka « Je déteste vraiment la politique ».
par rapport à
« Je ne me soucie généralement pas des catégories muettes, mais je veux encore pouvoir les parcourir parfois, alors gardez-les dans mes menus déroulants et dans les listes de catégories ».
N’est-ce pas l’action la plus simple et la plus cohérente à entreprendre que de simplement la modifier afin que nous ne commencions jamais à suivre automatiquement les sujets dans les catégories muettes ? Cela me semble être une meilleure option par défaut.
Finalement, vous finissez par créer la même fonctionnalité que tout le monde utilise déjà, mais vous finissez par masquer l’accès à celle-ci derrière cinq ou six autres préférences. L’équivalent Discourse du code Konami, si vous voulez.
Si le comportement de ces paramètres est jamais remanié, nous nous retrouvons de nouveau ici lorsque des publications commencent à apparaître là où elles ne devraient pas.
Au final, est-ce vraiment plus simple que de verrouiller l’accès pour supprimer « des derniers » via un paramètre du site ?
Je préfère nettement avoir des éléments du genre « Je veux partir dans une aventure étrange et merveilleuse » dans un plugin.
Fondamentalement, l’utilisateur a le droit de choisir ce qu’il voit dans « Derniers » et ce qu’il ne voit pas. Avoir un paramètre permettant des partitions étranges où l’utilisateur perd le contrôle me semble relever du domaine des plugins.
Je suppose que je suis plutôt ouvert à l’idée de créer un genre de plugin ici qui rétablirait l’ancienne fonctionnalité pour les rares sites qui tiennent vraiment, vraiment à cela ; avoir cette fonctionnalité anti-utilisateur dans le noyau me met mal à l’aise.
C’est une vision très sélective. Si vous êtes un employeur souhaitant offrir à votre personnel un environnement collaboratif et que vous envisagez d’autoriser des catégories « non professionnelles » limitées, une telle fonctionnalité peut être très souhaitable.
Elle a le potentiel d’être anti-utilisateur, mais il existe de nombreuses choses qui, si elles sont mal configurées, peuvent être destructrices pour une communauté.
Ce que nous (les personnes qui privilégions toujours l’« option de suppression ») essayons de souligner ici, c’est que
« En tant qu’administrateur du site, je veux contrôler le comportement des publications de catégories spécifiques afin qu’elles n’apparaissent pas dans /latest »,
ce que je continue de croire être complètement orthogonal à la question des « catégories muettes ».
Je pense que c’est une option viable (DWIM) concernant la question des « catégories muettes ». Néanmoins, cela ne résout pas l’exigence de « suppression de catégorie » pour certains d’entre nous.
Ce serait génial. Si ce n’est pas possible du tout de conserver cette fonctionnalité dans le cœur de Discourse, la placer dans un plugin dédié nous sauverait la mise.
Y a-t-il une possibilité de travailler là-dessus / de le publier en parallèle / bientôt lorsque la suppression de la fonctionnalité « suppression de catégorie » touchera plus de personnes ?
Merci encore pour votre écoute et cordialement,
Andreas.
N’est-ce pas, par définition, anti-utilisateur ? Vous dites : « Vous êtes tous des enfants, je ne peux pas vous faire confiance, même avec un minimum d’autodiscipline ici. Si vous voulez avoir ce genre de discussions, allez plutôt là-bas »
Je ne veux pas vous permettre de réactiver cette catégorie ; vous ne pourrez jamais la voir, sauf dans la prison que je vous ai construite.
Les employeurs ne sont pas tenus de créer de tels espaces. L’avantage évident est qu’ils facilitent l’adoption de nouveaux outils, mais vous ne voulez pas que ces ajouts de valeur prennent le pas sur l’objectif initial.
Je dirais que dans un environnement de travail, ce genre de compromis perd rapidement de sa pertinence avec des éléments comme le thème de la barre latérale, qui fonctionne extrêmement bien dans ce contexte. Cette fonctionnalité est en quelque sorte orthogonale à cela. Lorsque vous utilisez la barre latérale, vous passez généralement beaucoup moins de temps dans la section « Derniers » de toute façon.
Je comprends tout à fait et je reconnais votre point de vue ici. Utiliser la fonctionnalité « catégorie en sourdine » donnera plus de liberté à l’utilisateur, car elle pourra elle-même contrôler ce qu’elle reçoit dans /latest. Cependant, je tiens à souligner que la fonctionnalité « supprimer la catégorie » ne concerne pas nécessairement la censure du tout — du moins de notre point de vue.
Plutôt, nous voyons et utilisons la fonctionnalité « supprimer la catégorie » en tant que modérateurs comme un moyen de réduire le bruit provenant de catégories ayant occasionnellement ou définitivement un trafic élevé, afin de ne pas encombrer /latest pour tous les utilisateurs (anonymes et connectés).
Pour donner un autre exemple, cela pourrait provenir de publications automatisées vers des catégories spécifiques lors de l’utilisation d’outils comme GitHub - huw/github-to-discourse: Forwards commit data from a GitHub webhook to a Discourse thread · GitHub. Les publications provenant de ce genre d’outils ne sont même pas de « vraies discussions » dans ces contextes spécifiques où Discourse est utilisé au-delà de son cas d’usage original en tant que forum de discussion.
Si cela pourrait toucher certains rares sites ou non, c’est au-delà de ce que je peux imaginer. Alors, changeons de perspective pour dire que cela pourrait être une fonctionnalité cruciale pour certains sites exécutant des ensembles spécifiques de fonctionnalités ou répondant à des exigences particulières.
Ainsi, rendre cette fonctionnalité disponible via un plugin afin de satisfaire les besoins de ces types de sites spécifiques serait probablement tout à fait acceptable pour tous ceux qui argumentent ici et souhaitent conserver cette option.