Prioritizing closed or solved topics in search

[loginerror (Maciej Kuźmicz)]

@sam

Previously we bumped down priority of closed topics, but forgot about archived topics. This is now fixed.

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.

[Tris20 (Tristan)]

@sam

Previously we bumped down priority of closed topics, but forgot about archived topics. This is now fixed.

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.

@sam

How are the changes feeling to you (neutral/better/worse?)

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 . I don’t expect that to be matched, but improvements in that area would be a great step forward.

[mattdm (Matthew Miller)]

@sam

Very interesting problem, yes, they are (and always have been) de-prioritized. I think at a minimum we can look at adding a site setting to discourse-solved to allow admins to decide what to do in these cases (prioritize/deprioritize/neutral etc.)

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.

[Jagster (Jakke Lehtonen)]

@mattdm

it would be better to keep this consistent (that is, no per-site option)

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

So — the third option is the interesting one.

[mattdm (Matthew Miller)]

@Jagster

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

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.

[Jagster (Jakke Lehtonen)]

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 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

[sam (Sam Saffron)]

@Jagster

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.

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?

[mcwumbly (Dave McClure)]

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:

discourse/discourse/blob/6ae0c42c0156ce3f4861731e4872be026be2eeef/lib/search.rb#L1156-L1172

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?

[mattdm (Matthew Miller)]

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.

[mcwumbly (Dave McClure)]

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

@mattdm

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

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)

[mattdm (Matthew Miller)]

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.

[mcwumbly (Dave McClure)]

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?

[matenauta]

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

[mattdm (Matthew Miller)]

@mcwumbly

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?

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! ↩︎

[mcwumbly (Dave McClure)]

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.

[tpetrov (Toni Petrov)]

@mattdm

Closed posts with no solution are nearly worthless

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.

[mattdm (Matthew Miller)]

@tpetrov

@mattdm

Closed posts with no solution are nearly worthless

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.

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.)

[sam (Sam Saffron)]

@mcwumbly

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?

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.

[sam (Sam Saffron)]

@mcwumbly its one of those where doing the work is actually easier than specing the work…

I made an attempt at:

FEATURE: search_rank_sort_priorities modifier

FEATURE: prioritize_solved_topics_in_search to prioritize solved topics

[pfaffman (Jay Pfaffman)]

@sam

its one of those where doing the work is actually easier than specing the work

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.