我们目前在 meta.discourse.org 上似乎还没有一个 Data Explorer 查询的实时库。解决这个问题是否值得？
此处提到的主题内容杂乱无章，且已被关闭：
@SidV 在 GitHub 上建立了一个很棒的集合：
现在是不是在 Meta 上建立一个由社区管理的库的合适时机？我认为许多人会觉得这很有用。
10 个赞
是的，该主题收到了太多问题和回复，导致无法阅读。
我也这么认为。有人对如何在此站点上组织 Data Explorer 查询有想法吗？理想情况下，应该能够通过搜索几个关键词来查找现有的查询。
6 个赞
几点想法：
- 我们可以设立一个单独的类别，每个主题对应一个查询。为避免杂乱，新主题可能需要工作人员审批。
- 也可以仅为单个主题添加
data-explorer-query标签。这些主题可以放在 #howto:tips-and-tricks 中。
10 个赞
感谢邀请我分享 
我乐于调整 GitHub 上查询列表的分类方式。或许我们可以先共同思考一下分类方案，在充分调试好各个类别后，再将其迁移到这里的 Meta 讨论区（？）。
欢迎随时提交 PR。
5 个赞
我之前没意识到每个查询都可以发起拉取请求（PR）、分叉（fork）等等。这确实很酷，我也明白你为什么要这么做。不过，对于技术背景较弱的用户来说，这可能有点令人困惑。所有 Discourse 管理员都熟悉 Discourse，但只有一部分人熟悉 GitHub。
你说的“分类”具体指什么？我觉得用标签（tags）来处理这方面会很合适。
我认为设立一个专门的 #plugin 子版块是最佳方案。
- 如果我们采用“一个查询一个主题”的方式，主题数量会非常多。@SidV 已经有 70 多个了，而且外面还有很多。这将严重污染/淹没 #howto:tips-and-tricks！
- 这样可以让每个主题都成为 Wiki，配置为跳转到首帖，并提供建议的结构作为模板。
- 这也与 #plugin 版块配置保持一致，这样非常棒！
2 个赞
我建议将所有有用且高效的查询整合到一个主题中，随后将其锁定。
该主题将成为经过验证查询的“唯一真实来源”。
此后，我们可以对添加到该主题中的条目结构稍加严格。每个条目都应包含一个描述性的标题、一段简短的功能说明，并提及作者以表致谢。
完成这一步后，我们可以在该主题中添加目录，其中为每个查询设置一个标题。
针对 Simon 在此处的担忧：
新版目录组件将配备一个实时、位于帖子内的搜索栏，可搜索每个部分的标题和内容，效果如下所示。
（暂且忽略样式，目前仍在开发中）
新版组件预计将在今年年底左右具备生产环境就绪条件。
至于分享、建议或请求新查询的流程，我们可以为此创建一个新主题。在该主题中分享的优秀查询随后将被添加到包含目录的“唯一真实来源”主题中。
7 个赞
我觉得更好的做法是制定一个流程，将查询请求整合到数据探索器中。
或许可以创建一个带有 #feature 标签（同时标记 data-explorer 和 #candidate-query）的议题，用于提交候选查询。该议题需说明为何应将其整合、其独特性以及重要性。
随后，我们评估该提案是否合理，若合理则将其整合并关闭议题。
如果确实需要，您随时可以浏览那些被拒绝的整合请求。
8 个赞
在数据探索器中扩展原生的查询功能，无疑会对许多管理员和用户提供极大的帮助，并提升其易用性。
不过，我认为同样存在对“二级”查询的需求，以及一个专门讨论这些查询的结构化场所。我来元讨论区是为了寻找解决自身问题的方案，而非单纯为了贡献巧妙的查询。
也许可以将 @sam 和 @Johani 的方法结合起来？创建一个子分类，其中包含一些被标记为“官方”的主题或查询，并将它们与插件捆绑发布。
1 个赞
关于此问题的一个小更新——我们现在有了一个 Data & reporting 类别。
我会回顾一下这个话题中的建议，看看还有没有其他可以借鉴的想法。
5 个赞