# Prioriser les sujets fermés ou résolus dans la recherche
**URL:** https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992
**Category:** Feature
**Tags:** search
**Created:** [Février 9, 2023, 12:21 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992 "2023-02-09T00:21:42Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@loginerror](https://meta.discourse.org/u/loginerror)
#### Post date: [Février 6, 2023, 9:34 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/1 "2023-02-06T09:34:38Z")
> [@sam](#):
>
> Précédemment, nous avions réduit la priorité des sujets **fermés** , mais nous avions oublié les sujets **archivés**. Ceci est [maintenant corrigé](https://github.com/discourse/discourse/commit/5d28cb709acff03dfab4675fa86032fcc96ed5f2).
Petite question à ce sujet. Qu’en est-il des sujets auto-fermés avec une solution ? Logiquement, on veut qu’ils apparaissent car ils ont une solution, mais si j’ai bien compris, ils sont actuellement automatiquement moins visibles.
---
### Author:  [@Tris20](https://meta.discourse.org/u/Tris20)
#### Post date: [Février 6, 2023, 1:31 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/2 "2023-02-06T13:31:42Z")
> [@sam](#):
>
> Auparavant, nous avions réduit la priorité des sujets **fermés** , mais nous avions oublié les sujets **archivés**. C’est [maintenant corrigé](https://github.com/discourse/discourse/commit/5d28cb709acff03dfab4675fa86032fcc96ed5f2).
Est-ce quelque chose que nous pouvons activer avec un paramètre de site ? Dans certains cas, un sujet peut être fermé et résolu. Inversement, certains utilisateurs pourraient même s’attendre à ce qu’il soit _plus haut_ dans les résultats.
> [@sam](#):
>
> Comment trouvez-vous les changements (neutre/mieux/pire ?)
Je suis très heureux de voir que la recherche reçoit de l’attention. Pouvoir rechercher spécifiquement par catégorie est déjà un grand avantage pour notre cas d’utilisation.
La seule chose sur laquelle j’aimerais voir une amélioration est la gestion des fautes d’orthographe courantes. Certains moteurs de recherche m’ont tellement gâté que je tape paresseusement les touches jusqu’à ce qu’un mélange de lettres qui ressemble vaguement au mot d’origine se trouve dans la barre de recherche 😅. Je ne m’attends pas à ce que cela soit égalé, mais des améliorations dans ce domaine seraient un grand pas en avant.
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [Février 9, 2023, 12:21 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/3 "2023-02-09T00:21:42Z")
> [@sam](#):
>
> Problème très intéressant, oui, ils sont (et ont toujours été) dépriorisés. Je pense qu’au minimum, nous pouvons envisager d’ajouter un paramètre de site à discourse-solved pour permettre aux administrateurs de décider quoi faire dans ces cas (prioriser/déprioriser/neutre, etc.).
Opinion tranchée ! Je pense qu’il serait préférable de maintenir la cohérence (c’est-à-dire pas d’option par site), et :
1. _Augmenter_ la priorité des publications **fermées** qui sont **résolues** (à un niveau _supérieur_ aux publications ouvertes).
2. Ajouter la possibilité d’une minuterie (idéalement, par catégorie et/ou par balise) pour **archiver** automatiquement les publications fermées.
3. Au sein des publications archivées, privilégier celles qui ont des solutions — mais pas au point qu’elles apparaissent avant les publications non archivées.
Avertissement : oui, je veux cette fonctionnalité d’archivage automatique pour mon propre site ! Mais je pense qu’elle a du sens en général. Tout ce qui a une réponse mais est probablement non pertinent devrait être balayé. Et si vous ne le souhaitez pas (vos questions résolues sont intemporelles), n’activez pas l’archiveur.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [Février 9, 2023, 7:32 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/4 "2023-02-09T07:32:43Z")
> [@mattdm](#):
>
> il serait préférable de garder cela cohérent (c’est-à-dire pas d’option par site)
Pourquoi, parce que cela facilite le travail du développeur ? Ou parce que cela facilite la vie des utilisateurs lorsqu’ils passent d’un Discourse à l’autre ? Autre chose ?
La première raison n’est pas une raison du tout — tant que la charge de travail est humaine et qu’une tâche est possible dans cette réalité. La seconde est une bonne raison pour MS ou Apple, qui ne veulent pas trop se battre avec les clients, mais sinon — en tant qu’administrateur et créateur de contenu, je veux servir mes utilisateurs, pas garder les choses similaires ici, là ou ailleurs 😉
Donc — la troisième option est la plus intéressante.
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [Février 9, 2023, 7:41 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/5 "2023-02-09T07:41:57Z")
> [@Jagster](#):
>
> Pourquoi, parce que cela facilite le côté développeur ? Ou parce que cela facilite la vie des utilisateurs lorsqu’ils passent d’un Discourse à l’autre ? Autre chose ?
Les deux. Et parce que cela réduit la complexité _administrative_. Au lieu d’une tonne d’options supplémentaires (et de la possibilité de ne même pas réaliser qu’il existe un paramètre pour faire ce que vous voulez), prenez du recul et trouvez un schéma général pour que le schéma souhaité _fonctionne simplement_ dans la plupart des cas.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [Février 9, 2023, 8:07 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/6 "2023-02-09T08:07:51Z")
C’est certainement un point fort.
Mais. Pourrions-nous utiliser une autre solution, tout en restant familière : les paramètres cachés ?
Je vois ici deux stratégies différentes maintenant :
- les administrateurs devraient-ils avoir carte blanche pour ajuster des parties importantes, comme les résultats de recherche, car les besoins de la communauté sont différents et ne dépendent pas de la plateforme (c’est une question de codage/développement)
- les administrateurs doivent-ils être traités comme d’autres utilisateurs et garder les choses ordonnées et claires en termes d’expérience utilisateur, et laisser CDCK décider quoi, où et pourquoi
En regardant #Support, les deux voies ont des avantages et des inconvénients 😉 Mais quand même — la première direction fait un peu plus partie du monde open source, tandis que la seconde est la voie d’Apple.
Plus d’options génère plus de questions et de problèmes créés par des administrateurs pas si compétents comme moi. Plus d’options peuvent donner de meilleurs résultats pour les utilisateurs et les visiteurs. Alors ?
Pour moi, la question est très simple : je veux obtenir une recherche aussi puissante que possible, et si la clôture d’un sujet diminue son classement dans les résultats de recherche, je ne ferme plus les sujets ou très rarement. Choix facile, mais je dois alors agir à cause des limitations du logiciel, pas à cause des besoins de la communauté.
Alors — les stratégies sont une chose différente des tactiques 😉
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Février 10, 2023, 2:07 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/7 "2023-02-10T02:07:18Z")
> [@Jagster](#):
>
> Pour moi, la question est très simple : je veux obtenir une recherche aussi puissante que possible, et si la fermeture d’un sujet diminue son classement dans les résultats de recherche, je ne ferme plus les sujets ou très rarement. Choix facile, mais je dois alors agir à cause des limitations du logiciel, pas à cause des besoins de la communauté.
Nous avons de nombreux précédents pour les options ici, nous avons une priorité de recherche par catégorie que tout administrateur peut configurer.
Je ne suis certainement pas contre quelques options supplémentaires sur la façon dont le bonus “archivé/fermé/résolu” augmente (ou diminue) dans les résultats de recherche.
C’est un peu une quête secondaire, nous recommandons de la diviser dans un autre sujet avec une proposition claire sur les paramètres qui auraient du sens ?
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [Avril 26, 2023, 5:59 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/8 "2023-04-26T17:59:58Z")
J’aimerais déterminer les prochaines étapes possibles pour un changement ici compte tenu de l’intérêt exprimé jusqu’à présent.
Actuellement, voici la logique :
>
selon @sam :
> remarquez le cas limite ici !
>
> Sur meta… étant donné le bruit sur #Support, nous avons tendance à vouloir le déprioriser… une fois dépriorisé, le bonus de classement fermé n’a plus d’effet…
Il faut donc aussi considérer comment cela interagit avec les pondérations des catégories.
Je pense qu’une approche itérative ici pourrait être la suivante :
1. Ajouter simplement un cas pour résolu `WHEN topics.solved then 1.1`
2. Changer les pondérations archivé, fermé et résolu pour qu’elles soient des **multiplicateurs** de la pondération de la catégorie et les unes des autres.
3. Rendre les multiplicateurs de pondération archivé, fermé et résolu configurables via les paramètres du site
Peut-être que cela a du sens de faire tout cela en même temps. Ou peut-être que nous faisons (1) et (2) d’abord et attendons avant de les rendre configurables. Qu’en penses-tu @sam ?
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [Avril 26, 2023, 6:14 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/11 "2023-04-26T18:14:57Z")
Utiliser des multiplicateurs semble être une approche généralement bonne, mais je pense qu’il est difficile d’exprimer ce que je suggérais ci-dessus.
```
fermé non résolu < ouvert non résolu < ouvert résolu < fermé résolu
```
Fermé devrait être une augmentation de priorité pour les publications résolues mais une _diminution_ pour celles non résolues.
Les publications fermées sans solution n’ont quasiment aucune valeur — quelqu’un d’autre a eu ce problème, mais il n’y a pas de réponse ici, et vous ne pouvez pas en fournir une. Les publications fermées _avec_ des solutions, en revanche, sont de l’or. Elles ne sont pas simplement résolues, mais de manière définitive.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [Avril 26, 2023, 6:29 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/12 "2023-04-26T18:29:00Z")
OK, et de plus, vous avez également mentionné les sujets archivés plus tôt :
> [@mattdm](#):
>
> - _Augmenter_ la priorité des publications **fermées** qui sont **résolues** (à un niveau _supérieur_ à celui des publications ouvertes).
> - Ajouter la possibilité d’une minuterie (idéalement, par catégorie et/ou par étiquette) pour **archiver** automatiquement les publications fermées.
> - Dans les publications archivées, privilégier celles qui ont des solutions — mais pas au point qu’elles apparaissent avant les publications non archivées.
Donc, si je comprends bien, vous préféreriez classer les choses de cette façon ?
(du plus élevé au plus bas)
1. fermé résolu
2. ouvert résolu
3. ouvert non résolu
4. fermé non résolu
5. archivé résolu
6. archivé non résolu
(Et ensuite ajouter la complexité superposée des classements par catégorie d’une manière ou d’une autre)
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [Avril 26, 2023, 6:31 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/13 "2023-04-26T18:31:43Z")
Oui, essentiellement, bien que l’ordre des publications archivées n’ait probablement pas d’importance :
Les publications archivées avec des solutions sont probablement non pertinentes, mais peuvent être historiquement intéressantes. Les publications archivées sans solutions sont essentiellement les mêmes — si vous recherchez dans les archives, c’est probablement pour l’histoire, donc l’état résolu est une information, mais si cela importe laquelle c’est, vous devriez l’inclure explicitement dans votre requête.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [Avril 26, 2023, 6:33 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/14 "2023-04-26T18:33:50Z")
Utilisez-vous vous-même des pondérations de catégorie ? Si oui, avez-vous des opinions sur la façon dont cette pondération devrait remplacer ces pondérations basées sur l’état telles qu’elles sont actuellement ou être multiplicative ?
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [Avril 26, 2023, 6:38 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/15 "2023-04-26T18:38:46Z")
Je pense que le commutateur pour examiner une catégorie spécifique est suffisant et pourrait être utile pour ignorer ce poids lors de la recherche (car les gens recherchent des solutions, pas des catégories ou des sujets/catégories suggérés).
Mon grain de sel, je suis entièrement d’accord avec ce que vous faites ici 👌
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [Avril 26, 2023, 7:04 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/16 "2023-04-26T19:04:59Z")
> [@mcwumbly](#):
>
> Utilisez-vous des pondérations de catégorie vous-même ? Si oui, avez-vous une opinion sur la manière dont cette pondération devrait remplacer ces pondérations basées sur l’état, comme elles le sont actuellement, ou être multiplicative ?
Oui, je les utilise définitivement. Nous avons des catégories de « flux de travail » qui ne devraient pratiquement jamais apparaître, sauf si on les demande, et d’autres qui sont des annonces et des nouvelles qui sont plus importantes.
J’invente ça _maintenant_ donc je me réserve le droit d’être fluctuant dans mon opinion à l’avenir, mais je pense que je veux que les pondérations des catégories remplacent toutes les pondérations de statut du sujet, _sauf_ archivé. Je pense ici au cas des nouvelles. Celles-ci devraient apparaître en haut des résultats tant qu’elles sont fraîches, mais pas du tout après un certain temps. Et l’archivage des publications pourrait être la façon dont chaque site spécifie ce que « un certain temps » signifie là-bas.\[1\]
Alternativement, et peut-être plus simple : faites simplement en sorte que les pondérations des catégories l’emportent, puis introduisez une option par catégorie pour préférer les publications fraîches, et si elle est cochée, ayez un multiplicateur qui diminue avec le temps (de 2x à 0,5x, par exemple).
* * *
1. Et puis il y a toujours la demande de fonctionnalité d’archivage automatique après un certain temps, mais ce sont des détails, des détails !
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [Avril 26, 2023, 7:22 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/17 "2023-04-26T19:22:57Z")
OK, ce que j’entends, c’est que les pondérations de catégorie devraient avoir la priorité.
Je pense que les pondérations résolu/fermé/archivé devraient toujours s’appliquer _à l’intérieur_ d’une catégorie.
J’entends aussi votre point sur le minuteur automatique d’archivage… c’est complémentaire, mais je pense que nous pouvons obtenir des résultats ici d’abord sans cela.
---
### Author:  [@tpetrov](https://meta.discourse.org/u/tpetrov)
#### Post date: [Avril 26, 2023, 8:44 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/18 "2023-04-26T20:44:42Z")
> [@mattdm](#):
>
> Les publications fermées sans solution n’ont quasiment aucune valeur
Je ne suis pas d’accord ici. Un sujet peut avoir une bonne réponse, mais l’OP n’a pas pris la peine de la marquer comme solution/les solutions n’étaient pas disponibles s’il s’agit d’un sujet plus ancien, etc.
Un sujet ouvert a l’avantage de pouvoir être remonté, mais je ne lui accorderai pas trop d’importance. Je préférerais plutôt voir le contenu le plus pertinent basé sur les mots-clés.
Concernant l’archivage, je suis d’accord - pour moi, c’est du contenu qui n’est plus pertinent et qui peut avoir moins de poids.
---
### Author:  [@mattdm](https://meta.discourse.org/u/mattdm)
#### Post date: [Avril 26, 2023, 9:01 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/19 "2023-04-26T21:01:21Z")
> [@tpetrov](#):
>
> > [@mattdm](#):
> >
> > Les publications fermées sans solution ont une valeur quasi nulle
>
> Je ne suis pas d’accord ici. Un sujet pourrait avoir une bonne réponse, mais l’OP n’a pas pris la peine de la marquer comme solution/les solutions n’étaient pas disponibles s’il s’agit d’un sujet plus ancien, etc.
Pourquoi un tel sujet serait-il fermé ? (Et, par anticipation : « Parce que le site est configuré pour fermer les sujets après N jours » est une réponse à _comment_ le sujet a été fermé, pas _pourquoi_.)
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Avril 26, 2023, 11:38 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/20 "2023-04-26T23:38:34Z")
> [@mcwumbly](#):
>
> Peut-être que cela a du sens de faire tout cela en même temps. Ou peut-être que nous faisons (1) et (2) d’abord et attendons avant de les rendre configurables. Qu’en penses-tu @sam ?
Je pense que pour rendre ce changement gérable, la phase zéro est la plus simple :
1. Ajouter le paramètre de site `prioritize_solved_topics` par défaut à `true`.
2. Lorsque défini sur `true`, accorder 1.1 aux sujets résolus sans condition.
Cela ne résout pas toutes les bizarreries ici, mais cela nous permettrait de faire des progrès raisonnables rapidement.
Le problème est que, d’un point de vue extensibilité, ce n’est pas un changement facile du tout.
Il n’y a pas de colonne « résolu » dans la table des sujets, ce que nous sommes obligés de faire ici, c’est d’injecter une sorte de jointure depuis « résolu » dans les champs personnalisés des sujets… cela signifie que ce SQL doit être transformé d’une manière plutôt élaborée :
Soit
1. Nous devons injecter un `LEFT JOIN` dans le plugin « résolu » `LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id`
2. Nous devons transformer cette instruction `CASE`, ce qui signifie probablement rendre l’ensemble de l’instruction CASE composable à l’aide d’un plugin.
Alternativement, nous pourrions nous en sortir avec quelque chose comme `CASE EXISTS(...) THEN 1.1` qui élimine le besoin d’un left join mais comporte ses propres risques.
Je vais réfléchir à ce problème, le défi majeur ici est de trouver comment ne pas créer un énorme désordre en ajoutant ce support étant donné que le « cœur » ne sait rien des sujets résolus.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Mai 2, 2023, 6:07 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/22 "2023-05-02T06:07:54Z")
@mcwumbly c’est un de ces cas où faire le travail est en fait plus facile que de spécifier le travail…
J’ai fait une tentative sur :
>
>
> This new modifier can be used by plugins to modify search ordering.
>
> Specificall…y plugins such as discourse\_solved can amend search ordering
> so solved topics bump to the top.
>
> Also correct edge case where low and high sort priority categories did not
> order correctly when it came to closed/archived
>
>
> Many consumers of Discourse solve may want solved topics to show up more
> promine…ntly in search. New setting (default off) allows bumping these topics
> to the top.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Mai 3, 2023, 3:06 UTC](https://meta.discourse.org/t/prioritizing-closed-or-solved-topics-in-search/262992/23 "2023-05-03T15:06:12Z")
> [@sam](#):
>
> c’est l’un de ces cas où faire le travail est en fait plus facile que de spécifier le travail
C’est presque toujours le cas pour moi ! Je n’arrive presque jamais à comprendre la spécification avant d’avoir écrit le code qui, je pense, fonctionne. C’est (en partie) parce que j’écris généralement du code pour une spécification que je ne comprends pas. Quelques fois, j’ai pu écrire les spécifications d’abord comme un adulte, mais c’est assez rare.
C’est bien d’entendre que cela vous arrive au moins parfois aussi. 🙂