Un changement récent dans Discourse a supprimé la remontée de sujet lors de la modification du dernier (ou du premier message) dans un fil de discussion.
C’était une fonctionnalité sur laquelle nous comptions et il n’existe aucune méthode viable pour l’imiter pour les membres n’ayant pas le rang de personnel.
Nous bénéficions de cette fonctionnalité principalement pour remonter les messages de type annonce ou les messages qui ont intentionnellement reçu peu ou pas de réponses.
Il s’agissait de mises à jour réelles d’un sujet où une modification supprimait des informations désormais obsolètes. Le fait que le message remonte en haut du fil des derniers messages était très souhaitable car cela informait tous les membres qu’un changement avait eu lieu.
Oui, cela pourrait être imité dans une certaine mesure avec une chaîne de réponses, mais avec le temps, cela deviendra fastidieux pour l’utilisateur de comprendre ce qui était communiqué (imaginez 10 réponses avec des changements, par exemple). Il était beaucoup plus propre de modifier le message original / le message le plus récent et de laisser le sujet remonter dans le fil des derniers messages.
J’apprécie qu’il y ait des personnes des deux côtés de cette question, mais c’était un précédent établi de longue date dans Discourse pendant de nombreuses années, et l’ajout d’une option pour restaurer la fonctionnalité précédente dans Discourse satisfera tout le monde. Peut-être que l’option pourra être étendue avec le temps pour contrôler finement quelles activités sur un message constituent sa remontée dans le fil des derniers messages.
Un lien vers le fil de discussion du bogue où ce changement a été discuté se trouve ci-dessous :
Je ne peux pas voter sur ceci car je n’ai pas encore atteint le niveau de confiance requis, mais j’aimerais également exprimer mon approbation pour apporter ce changement, si c’est possible.
Comme je l’ai dit précédemment, l’envoi de sujets en haut de liste lors d’une modification significative me manque également.
J’utilise rss-polling pour être informé de la maintenance sur mon forum via le flux RSS de https://status.discourse.org/. Le sujet est créé lorsque la maintenance commence, et il était envoyé en haut de liste lors de la modification annonçant sa fin. Cet envoi est maintenant manquant, et je ne veux pas que les sujets soient des wikis, car aucun utilisateur ne devrait les modifier, ni ne veux qu’ils soient des documents. Les solutions de contournement actuelles n’aident donc pas.
Sur un forum, nous avons un sujet de galerie présentant les projets des utilisateurs en plus des sujets individuels dans lesquels les utilisateurs présentent leurs projets. Ce sujet est très utile pour rassembler de l’inspiration. Nous ajoutons une image du sujet de présentation et un lien vers celui-ci dans ce sujet de galerie. Trop d’images dans un message ont entraîné des problèmes de performance et rendent également la modification plus difficile. Nous créons donc un nouveau message pour tous les 10 projets. L’envoi en haut de liste lors de la modification lorsque le 2e ou le 9e projet a été ajouté était utile. Il est utile pour les utilisateurs de remarquer la mise à jour, et il était particulièrement utile pour ceux qui ajoutent des projets manuellement au sujet. Grâce à la date d’activité, je pouvais immédiatement voir si quelqu’un d’autre avait déjà ajouté le projet. Maintenant, chacun de nous doit ouvrir le sujet pour vérifier cela.
Il existe également d’autres sujets qui fonctionnent de manière similaire : des sujets qui servent de vue d’ensemble rétrospective des changements/activités au cours d’un mois et où le dernier message concernant le mois en cours est mis à jour plusieurs fois. Cela fonctionnait très bien car les modifications apportées au dernier message envoyaient le sujet en haut de liste. Publier chaque modification individuellement nuirait à la clarté des entrées regroupées mensuellement et signifierait toujours que les mises à jour des entrées existantes sont facilement manquées. Un nouveau sujet chaque mois pour quelques entrées semble excessif, et cela signifierait également que les utilisateurs devraient reconfigurer leurs notifications chaque mois, ou nous aurions besoin d’une sous-catégorie entière qui leur permette de définir leur statut de notification par défaut.
J’ai également apprécié que les changements de catégorie et d’étiquette sur les sujets sans réponse les envoient en haut de liste. Le plus souvent, j’utilise une liste (filtrée) des derniers sujets. Et si un sujet avait un titre mal choisi ou se trouvait dans la mauvaise catégorie, il se pourrait que je ne clique pas dessus. Si quelqu’un améliore cette information, je pourrais réaliser que je peux aider après tout. C’est pourquoi il était utile qu’un tel changement fasse remonter le sujet au-dessus de ma ligne de lecture.
De plus, il était utile d’en apprendre davantage sur les catégories et les étiquettes. J’ai souvent découvert de nouvelles étiquettes parce qu’elles étaient ajoutées à un nouveau sujet ou la différence détaillée entre les catégories en fonction des sujets déplacés par un modérateur. Je demande parfois pourquoi, car je pense que la possibilité de déplacer des sujets vers d’autres catégories s’accompagne également de la responsabilité de connaître la différence entre elles.
J’aime aussi l’approche selon laquelle les paramètres de Discourse vous obligent à ajouter des informations au lieu d’écrire un autre message.
Pour citer le message contextuel :
Cependant, cela n’a de sens que si les autres remarquent que vous avez modifié votre message pour ajouter des informations supplémentaires. Un exemple que j’ai rencontré plusieurs fois sur Meta concerne les mises à jour d’un message après la fusion d’une demande de tirage (pull request). L’ajout de ces informations dans le message n’informe pas ceux qui ont déjà lu le message, et ceux qui ne l’ont pas fait peuvent le voir facilement grâce au badge dans l’aperçu (onebox).
Pour moi, il n’est pas logique que le paramètre qui bloque plus de trois réponses consécutives par un utilisateur soit toujours actif et suggère des modifications comme solution, lorsque ces modifications n’ont malheureusement plus l’effet qu’elles avaient autrefois.
Je n’ai pas d’opinion tranchée sur cette fonctionnalité, mais un problème connexe est que j’aime remonter automatiquement les messages et ensuite supprimer le message indiquant qu’ils ont été remontés, mais ce n’est plus possible. Lorsque je supprime le message de remontée, le message redescend à l’endroit où il se trouvait auparavant. Si l’édition d’un message le faisait remonter sans créer un message du type « dernière remontée il y a 1 jour », ce serait utile.
(Je préférerais pouvoir le remonter, supprimer le message de remontée, et que le message reste sur la page d’accueil à moins que je ne fasse manuellement « réinitialiser la date de remontée ».)
Idée intéressante, tout ce qui permettrait de rétablir la fonctionnalité où les modifications faisaient remonter le message dans le fil d’activité serait apprécié
@lindsey y a-t-il quelque chose qui puisse être fait pour restaurer une partie de cette fonctionnalité ou est-ce que c’est trop tard maintenant et c’est la nouvelle norme
Je crains que nous n’ayons actuellement aucun plan pour annuler le changement / rétablir les remontées sur toutes les modifications. Je comprends que ce n’est pas la réponse que vous souhaitez entendre, cependant, et nous continuerons à surveiller ce sujet et à réfléchir à la manière dont nous pourrons mieux soutenir vos cas d’utilisation à l’avenir.
Le fait que quelque chose ne se produise plus ne l’est pas non plus. Y a-t-il des données sur le nombre d’administrateurs qui ont remarqué que le comportement de Discourse a changé ? Je comprends votre argument selon lequel il y avait des demandes répétées sur la façon d’empêcher les remontées. Il est évident que les administrateurs remarquent une remontée qu’ils ne souhaitent pas. Mais si un sujet n’est pas remonté, vous ne remarquez même pas qu’il n’a pas été remonté, même si vous auriez aimé qu’il le soit. Il semble donc moins probable que les gens demandent cela.
De plus, récemment, le fait que le spam soit plus facilement repérable si le sujet est remonté est réapparu. Je me demande pourquoi c’est pertinent dans le cas désormais plutôt limité où un message doit être remonté lors de la modification. Mais cela n’avait pas d’importance lors du changement de la valeur par défaut pour la plupart des messages. Pourquoi un premier message qui est un wiki a-t-il besoin de plus de protection contre le spam qu’un dernier message dans un sujet qui est un wiki ?
Comme je l’ai dit de nombreuses fois auparavant, je comprends les avantages, mais il ne semble pas y avoir beaucoup d’intérêt à trouver des solutions aux inconvénients. Cela ne sert à rien s’il y a un remplacement pour les flux de travail actuels après un an ou deux. Je devrai trouver une nouvelle solution maintenant car il ne reste plus beaucoup de temps où il existe une version prise en charge de Discourse où une modification du dernier message fait remonter le sujet.
Ceci n’est pas du tout motivé par la détection de spam.
Les publications Wiki et docs sont remontées sur la base de la théorie selon laquelle les modifications apportées à ces publications sont généralement intéressantes.
Quant à la protection anti-spam, la théorie actuelle est que ces remontées n’ont jamais vraiment apporté beaucoup de couverture supplémentaire. La plupart des publications ne sont pas la dernière publication, et les modifications qui y sont apportées n’étaient de toute façon jamais signalées par les remontées. Donc, si le spam via les modifications est un problème, il a besoin d’une solution différente quoi qu’il arrive. Ce n’était jamais vraiment une solution efficace à ce problème.
Je pense qu’il y a un malentendu. Mon propos ne concernait pas la raison pour laquelle les publications wiki dans le premier message sont remontées. Je parlais du raisonnement derrière la restriction du paramètre d’API no-bump, tel que mentionné dans le commentaire GitHub :
Faut-il restreindre cela aux clés d’API du personnel ? Je ne pense pas que nous voulions que les utilisateurs réguliers puissent contourner le remontage (cela leur permettrait d’injecter du spam dans les sujets sans attirer l’attention des gens).
Si le spam était vraiment la préoccupation, alors cette restriction devrait s’appliquer de manière cohérente, et pas seulement dans les quelques cas restants où le remontage se produit. C’est ce qui m’a surpris : le raisonnement cite le spam comme un problème ici, mais le remontage n’est pas censé être un mécanisme de protection contre le spam, par exemple, dans les wikis qui sont la dernière publication d’un sujet.
J’apprécie que les publications wiki soient remontées lors des mises à jour (bien que l’expérience utilisateur d’être redirigé vers le bas du sujet alors que la raison du remontage est la première publication soit toujours confuse).
Mon seul but est de souligner cette incohérence apparente concernant le spam.
Un autre cas où j’aurais aimé être informé de la modification du dernier message mais où je l’ai manqué parce que le sujet n’a pas été remonté : Restrict uploads - #30 by Arkshine