关于以上内容，有个快速的问题。带有解决方案的自动关闭主题呢？从逻辑上讲，人们希望这些主题显示出来，因为它们有解决方案，但如果我理解正确的话，那么现在这些主题的优先级会自动降低。
15 个赞
这是否可以通过站点设置来切换？在某些情况下，主题可能已关闭且已解决。反之，一些用户甚至可能期望它在结果中更高。
我很高兴看到搜索得到关注。能够按类别专门搜索对我们的用例来说已经是一个很大的优势。
我希望看到一点改进的是常见的拼写错误。一些搜索引擎已经把我宠坏了，以至于我会懒洋洋地敲击键盘，直到搜索栏中的字母组合只有稍微有点像原始单词 
。我不期望能完全匹配，但在该领域取得进步将是向前迈出的重要一步。
9 个赞
激进的看法！我认为最好保持一致（即，不提供每个站点的选项），并且：
- 提高 已关闭且已解决帖子的优先级（使其_高于_未关闭的帖子）。
- 添加一个计时器选项（最好是每个类别和/或每个标签），以自动归档已关闭的帖子。
- 在已归档的帖子中，优先显示有解决方案的帖子——但优先级不能高到让它们显示在未归档的帖子之上。
免责声明：是的，我确实希望为我自己的站点添加这个自动归档功能！但我认为它普遍适用。任何已回答但可能无关紧要的内容都应该被清除。如果你不想要（你的已解决问题是常青的），则不要启用归档器。
8 个赞
为什么，是因为这让开发人员更容易？还是因为用户在不同的 Discourse 之间切换时会更轻松？还是其他原因？
第一个原因根本不是原因——只要工作量是可接受的，并且任务在现实中是可能的。第二个原因是 MS 或 Apple 的好理由，它们不想在客户那里费太多力，但除此之外——作为一个管理员和内容创作者，我想为我的用户服务，而不是在这里、那里或别处保持事物相似 
所以——第三个选项很有趣。
4 个赞
两者都有。而且因为它降低了 管理员 的复杂性。与其提供更多的选项（以及可能根本没意识到有某个设置可以实现你想要的功能），不如退一步找到一个通用的模式，这样在大多数情况下，所需的模式 就能正常工作。
7 个赞
这绝对是一个强有力的论点。
但是。我们是否可以使用另一种熟悉的方法：隐藏设置？
我现在看到两种不同的策略：
- 管理员是否应该有自由裁量权来调整重要部分，例如搜索结果，因为社区的需求不同，并且不依赖于平台（这是编码/开发问题）
- 管理员是否应该被视为其他用户，并在用户体验方面保持整洁和清晰，让 CDCK 决定什么、在哪里以及为什么
看看 Support，这两种方式都有利有弊 但仍然——第一种方向在某种程度上更像是开源世界的一部分，而后一种方式是苹果的方式。
更多的选项会产生更多的问题，以及像我这样不太熟练的管理人员所带来的问题。更多的选项可以为用户和访问者带来更好的结果。那么呢？
对我来说，问题很简单：我希望获得尽可能强大的搜索功能，如果关闭一个主题会降低其在搜索结果中的排名，那么我就不再关闭主题，或者很少关闭。这是一个简单的选择，但随后我必须因为软件的限制而采取行动，而不是因为社区的需求。
所以——策略与策略是不同的
4 个赞
我们这里有很多可配置的选项，我们有每个类别的搜索优先级，任何管理员都可以配置。
我当然不反对围绕“存档/关闭/已解决”的帖子在搜索结果中加分（或减分）的更多设置。
这有点像一个支线任务，建议我们将其拆分到另一个主题中，并围绕哪些设置有意义提出明确的建议？
8 个赞
我想根据迄今为止表达的兴趣，来弄清楚这里可能采取的下一步措施。
目前，这是逻辑：
根据 @sam 的说法：
注意这里的边缘情况！
在 meta 上……鉴于 Support 的噪音，我们倾向于降低其优先级……一旦降低了优先级，关闭的排名奖励就不再生效……
因此，需要考虑的另一件事是这与类别权重如何配合。
我认为这里可以采取一种迭代的方法：
- 只需为已解决添加一个情况
WHEN topics.solved then 1.1 - 将已存档、已关闭和已解决的权重更改为类别权重和它们彼此的乘数。
- 通过站点设置使已存档、已关闭和已解决的权重乘数可配置。
也许一次性完成所有这些是有意义的。或者，我们先完成 (1) 和 (2)，然后再考虑使其可配置。你觉得怎么样 @sam？
3 个赞
使用乘数似乎是一个普遍可行的方法，但我认为很难表达我上面提出的建议。
已关闭但未解决 < 已打开但未解决 < 已打开且已解决 < 已关闭且已解决
“已关闭”应该会提高已解决帖子的优先级，但会降低未解决帖子的优先级。
没有解决方案的已关闭帖子几乎一文不值——其他人遇到了这个问题，但这里没有答案，你也无法提供。另一方面，有解决方案的已关闭帖子是无价的。它们不仅已解决，而且是明确已解决的。
4 个赞
好的，此外，您之前也提到了已存档主题：
那么，如果我理解正确的话，您更倾向于按此方式排序？
（从最高到最低）
- 已关闭已解决
- 未关闭已解决
- 未关闭未解决
- 已关闭未解决
- 已存档已解决
- 已存档未解决
（然后再加上某种方式的类别排名分层复杂性）
2 个赞
是的，基本上是这样，尽管已存档帖子的顺序可能无关紧要：
带有解决方案的已存档帖子可能无关紧要，但可能具有历史意义。没有解决方案的已存档帖子基本上是相同的——如果你在查找存档，那可能是为了历史原因，所以已解决的状态是信息，但如果它很重要，你应该在查询中明确包含它。
2 个赞
您自己会使用类别权重吗？如果使用，您觉得这些权重应该像现在这样覆盖基于状态的权重，还是应该相乘？
1 个赞
我认为用于查看特定类别的开关已经足够了，并且可以在搜索时忽略该权重（因为人们在搜索解决方案，而不是类别或建议的主题/类别）。
我的一点看法，我完全同意你在这里所做的一切 
2 个赞
是的，绝对使用它们。我们有一些“工作流”类别，除非被要求，否则它们基本上永远不会出现，而另一些则是公告和新闻，它们更重要。
我现在就在想这个问题，所以我保留将来对我的观点有所动摇的权利，但我的感觉是，我希望类别权重覆盖所有主题状态权重，_除了_已归档的。我在这里想到的是新闻案例。它们在新鲜的时候应该在结果中排名靠前，但过一段时间后就完全不出现了。归档帖子可以是每个网站指定“一段时间”意味着什么的自己的方式。[1]
或者，也许更简单：只需让类别权重覆盖，然后引入一个每个类别的选项来优先显示新鲜帖子，如果选中该选项，则有一个随时间下降的乘数（例如，从 2 倍到 0.5 倍）。
然后仍然有基于计时器的自动归档的RFE，但细节，细节！ ↩︎
2 个赞
好的，我听到的是类别权重应该优先。
我认为已解决/已关闭/已存档的权重仍然应该在类别内适用。
我也听到了关于存档自动计时器的说法……它是互补的，但我认为我们可以在没有它的情况下先取得一些进展。
1 个赞
我不同意。一个主题可能有一个很好的答案，但发帖人（OP）没有费心将其标记为解决方案/解决方案不可用（如果是旧主题等）。
一个开放的主题的好处是你可以顶它，但我不会太看重这一点。我更愿意根据关键词看到更相关的内容。
关于存档，我同意——对我来说，这是不再相关的内容，可以减轻其权重。
2 个赞
为什么这样的主题会被关闭？（并且，先发制人地回答：“因为网站设置为在 N 天后关闭主题”是回答 如何 关闭主题，而不是 为什么。）
3 个赞
我认为为了使这次更改易于管理，零阶段是微不足道的：
- 添加站点设置
prioritize_solved_topics，默认为true - 当设置为
true时，无条件地给予已解决主题 1.1。
这并不能解决这里的所有怪癖，但可以让我们快速取得合理的进展。
从可扩展性的角度来看，这并非易事。
topics 表中没有“已解决”列，我们在这里卡住的是从已解决插件注入某种连接到主题自定义字段……这意味着 SQL 需要以一种相当复杂的方式进行转换：
要么
-
我们需要在已解决插件中注入一个
LEFT JOINLEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
我们需要转换这个条件
CASE语句，这可能意味着使用插件使整个 CASE 语句可组合。
或者，我们可能可以得到类似 CASE EXISTS(...) THEN 1.1 的结果，这消除了左连接的需要，但也有其自身的风险。
我会仔细考虑这个问题，这里巨大的挑战是如何在“核心”不知道已解决主题的情况下，通过添加此支持而不造成一团糟。
8 个赞
@mcwumbly 这是那种实际动手做比规定工作更容易的情况……
我尝试了：
7 个赞
对我来说，几乎所有情况都是这样！我几乎总是在写我认为能工作的代码之后，才能弄清楚规范。这（部分）是因为我通常是为我不理解的规范编写代码。有几次我能够像个成年人一样先写规范，但这很少见。
很高兴听到这种情况至少有时也会发生在您身上。 
5 个赞