Prioritizing closed or solved topics in search

Quick question about the above. What about auto-closed topics with a solution? Logically, one wants those to show up because they have a solution, but if I got it right, then right now those are automatically less prominent.

15 Likes

Is this something we can toggle with a site setting? In some cases a Topic may be Closed and Solved. Conversely some users may even expect that to be higher in the results.

Iā€™m very happy to see search getting some attention. Being able to search specifically by category is already a big plus for our use case.

The one thing I would love to see a bit of improvement on is common spelling mistakes. Some search engines have spoiled me to the point that I will lazily slap the keys until a mixture of letters that only vaguely resemble to original word are in the search bar :sweat_smile:. I donā€™t expect that to be matched, but improvements in that area would be a great step forward.

9 Likes

Hot take! I think it would be better to keep this consistent (that is, no per-site option), and:

  1. Increase priority of closed posts which are solved (to greater than open posts).
  2. Add the option of a timer (ideally, per category and/or per tag) to automatically archive closed posts.
  3. Within archived posts, prioritize those with solutions ā€” but not so much that they show over non-archived posts.

Disclaimer: why yes, I do want that auto-archive feature for my own site! But I think it makes sense generally. Anything thatā€™s answered but probably irrelevant should be swept away. And if you donā€™t want that (your solved questions are evergreen), donā€™t enable the archiver.

8 Likes

Why, because it makes dev-side easier? Or because it makes usersā€™ life easier when they jump between Discourses? Something else?

First reason isnā€™t reason at all ā€” as long workload is humane and a task is possible in this reality. Second one is good reason for MS or Apple, who doesnā€™t want struggle too much with customers, but otherwise ā€” as an admin and content creator I want serve my users, not keep things similar than here, there or elsewhere :wink:

So ā€” the third option is the interesting one.

4 Likes

Both. And because it reduces admin complexity. Instead of a bunch more options (and opportunity to not even realize thereā€™s a setting to do what you want), step back and find a general pattern so the desired pattern just works in most cases.

7 Likes

That is defenetly a strong point.

But. Could we use another and yet familiar solution: hidden settings?

I see here two different strategies now:

  • should admins have free hands to tune up important parts, like search results, because needs of community are different and isnā€™t depending of platform (that is coding/dev question)
  • should admins be treated as another users and keep things tidy and clean UX-wise, and let CDCK decide what, where and why

Looking at support both ways have pros and cons :wink: But still ā€” the first direction is kind of more part of open source world, when the latter is Appleā€™s way.

More options generates more questions and issues made by not-so-skilled admins like me. More options can give better results for users and visitors. So?

For me the question is very easy: I want to get as powerful search as possible, and if closing a topic will decrease its ranking in search results I donā€™t close topics anymore or very rarely. Easy choise, but then I have to act because of limitations of software, not because of needs of community.

So ā€” strategies are different thing than tactics :wink:

4 Likes

We have plenty of precedents for knobs here, we have search priority per category which any admin can configure.

I am certainly not against some more knobs around how ā€œarchived/closed/solvedā€ bonus up (or down) in search results.

It is a bit of side quest, recommend we split it off to another topic with a clear proposal around what setting/s would make sense?

8 Likes

Iā€™d like to work out what next steps might be for a change here given the interest expressed so far.

Currently, this is the logic:

per @sam:

notice the edge case here!

At metaā€¦ given the noise on support we tend to want to deprioritise itā€¦ once deprioritized closed ranking bonus no longer takes effectā€¦

So something else to consider is how this plays with category weights.

I feel like an iterative approach here could be the following:

  1. Just add a case for solved WHEN topics.solved then 1.1
  2. Change the archived, closed, and solved weights to be multipliers of the category weight and each other.
  3. Make archived, closed, and solved weight multipliers configurable via site settings

Maybe it makes sense to do all of these at once. Or maybe we do (1) and (2) first and wait before making them configurable. What do you think @sam?

3 Likes

Using multipliers seems like a generally-good approach, but I think is hard to express what I was suggesting above.

closed not solved < open not solved < open solved < closed solved

Closed should be a priority increase for solved posts but a decrease for unsolved ones.

Closed posts with no solution are nearly worthless ā€” someone else had this problem, but thereā€™s no answer for it here, and you canā€™t provide one. Closed post with solutions are, on the other hand, gold. Theyā€™re not merely solved, but definitively so.

4 Likes

OK, and furthermore, you mentioned archived topics earlier too:

So if I understand correctly, youā€™d prefer to rank things this way?

(from highest to lowest)

  1. closed solved
  2. open solved
  3. open not solved
  4. closed not solved
  5. archived solved
  6. archived not solved

(And then add on the layered complexity of category rankings somehow too)

2 Likes

Yes, basically, although the order of archived posts probably doesnā€™t matter:

Archived posts with solutions are likely-irrelevant but may be historically interesting. Archived posts without solutions are basically the same ā€” if youā€™re looking in the archive, itā€™s probably for history, so the solved state is information but if it matters which one it is you should include that explicitly in your query.

2 Likes

Do you use category weightings at all yourself? If so, do you have feelings about how whether that weighting should override these state-based weights as they are now or be multiplicative?

1 Like

I think the switch for look into specific category are enough and could be good to discard that weight when searching (because people are searching solutions, not categories or suggested topics/categories).

My two cents, Iā€™m fully agree with what you are doing here :ok_hand:

2 Likes

Yes, definitely use them. Weā€™ve got some ā€œworkflowā€ categories which should basically never come up unless asked for, and others that are announcements and news that are more important.

I am making this up right now so I reserve my right to be flaky in my opinion in the future, but my feeling is that I want the categories weights to override all of the topic-status weights, except archived. Iā€™m thinking of the news case here. Those should come up high in results while theyā€™re fresh, but not at all after some amount of time. And archiving posts could be each siteā€™s way of specifying what ā€œsome amount of timeā€ means there.[1]

Alternately, and maybe more simple: just have category weights overrule, and then introduce a per-category option to prefer fresh posts, and if thatā€™s checked have a multiplier that drops over time (from 2x to 0.5x, say).


  1. And then thereā€™s still the auto-archive-on-a-timer RFE, but details, details! ā†©ļøŽ

2 Likes

OK, what Iā€™m hearing is that category weights should take precedence.

I think we should have the solved/closed/archived weights still apply within a category.

I hear you on the archive auto-timer thing as wellā€¦ itā€™s complementary, but I think we can get some mileage here first without it.

1 Like

Iā€™d disagree here. A topic might have a good answer, but the OP didnā€™t bother to mark it as solution/solutions werenā€™t available if itā€™s an older topic, etc.
An open topic has the pro that you can bump it, but I wouldnā€™t put too much weight on that. Iā€™d rather prefer to see the more relevant content based on keywords.

Regarding archived I agree - to me this is content that isnā€™t relevant any more and can have less weight.

2 Likes

Why would such a topic be closed? (And, preemptively: ā€œBecause the site is set to close topics after N daysā€ is an answer to how the topic was closed, not why.)

3 Likes

I think to keep this change manageable phase zero is the trivial:

  1. Add site setting prioritize_solved_topics default true
  2. When set to true, give solved 1.1 unconditionally.

It does not solve all of the quirks here, but it would give us reasonable amount of progress quickly.

Trouble is from an extensibility perspective this is not an easy change at all.

There is no ā€œsolvedā€ column on the topics table, what we are stuck doing here is injecting some sort of join from solved into topic custom fieldsā€¦ this mean this SQL needs to be transformed in a rather elaborate way:

Either

  1. We need to inject a LEFT JOIN in the solved plugin LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id

  2. We need to transform this conditions CASE statement, which probably means making the whole CASE statement composable using a plugin.

Alternatively we may get away with something like CASE EXISTS(...) THEN 1.1 which eliminates needing a left join but comes with its own risks.

Will have a think about this problem, the huge challenge here is figuring out how not to create a giant mess by adding this support given ā€œcoreā€ knows nothing about solved topics.

8 Likes

@mcwumbly its one of those where doing the work is actually easier than specing the workā€¦

I made an attempt at:

7 Likes

Thatā€™s darn-near every one for me! I can almost never figure out the spec until Iā€™ve written the code that Iā€™m pretty sure works. This is (partly) because Iā€™m usually writing code for a spec that I donā€™t understand. A couple of times Iā€™ve been able to write the specs first like a grown-up, but itā€™s pretty rare.

Itā€™s good to hear that it at least sometimes happens to you too. :slight_smile:

5 Likes