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.
15 « J'aime »
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.
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.
9 « J'aime »
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 :
- Augmenter la priorité des publications fermées qui sont résolues (à un niveau supérieur aux publications ouvertes).
- Ajouter la possibilité d’une minuterie (idéalement, par catégorie et/ou par balise) pour archiver automatiquement les publications fermées.
- 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.
8 « J'aime »
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.
4 « J'aime »
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.
7 « J'aime »
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
4 « J'aime »
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 ?
8 « J'aime »
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 :
- Ajouter simplement un cas pour résolu
WHEN topics.solved then 1.1 - 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.
- 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 ?
3 « J'aime »
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.
4 « J'aime »
OK, et de plus, vous avez également mentionné les sujets archivés plus tôt :
Donc, si je comprends bien, vous préféreriez classer les choses de cette façon ?
(du plus élevé au plus bas)
- fermé résolu
- ouvert résolu
- ouvert non résolu
- fermé non résolu
- archivé résolu
- archivé non résolu
(Et ensuite ajouter la complexité superposée des classements par catégorie d’une manière ou d’une autre)
2 « J'aime »
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.
2 « J'aime »
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 ?
1 « J'aime »
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 
2 « J'aime »
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).
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 ! ↩︎
2 « J'aime »
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.
1 « J'aime »
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.
2 « J'aime »
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.)
3 « J'aime »
Je pense que pour rendre ce changement gérable, la phase zéro est la plus simple :
- Ajouter le paramètre de site
prioritize_solved_topicspar défaut àtrue. - 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
-
Nous devons injecter un
LEFT JOINdans 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 -
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.
8 « J'aime »
@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 :
7 « J'aime »
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. 
5 « J'aime »