我们目前在 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）来处理这方面会很合适。
我认为将其放在 Customization > Plugin 分区下的一个专用子分区是最好的选择。
- 如果我们采用每个主题一个查询的方式，将会产生大量主题。@SidV 已经有超过 70 个了，外面还有更多。这将严重污染/淹没 #howto:tips-and-tricks 分区！
- 这将使得每个主题都可以设置为 Wiki，配置为「跳转到首帖」，并拥有一个作为模板的建议结构。
- 它还将与 Customization > Plugin 分区的配置保持一致，这样看起来很协调！
2 个赞
我建议将所有有用且高效的查询整合到一个主题中，随后将其锁定。
该主题将成为经过验证查询的“唯一真实来源”。
此后，我们可以对添加到该主题中的条目结构稍加严格。每个条目都应包含一个描述性的标题、一段简短的功能说明，并提及作者以表致谢。
完成这一步后，我们可以在该主题中添加目录，其中为每个查询设置一个标题。
针对 Simon 在此处的担忧：
新版目录组件将配备一个实时、位于帖子内的搜索栏，可搜索每个部分的标题和内容，效果如下所示。
（暂且忽略样式，目前仍在开发中）
新版组件预计将在今年年底左右具备生产环境就绪条件。
至于分享、建议或请求新查询的流程，我们可以为此创建一个新主题。在该主题中分享的优秀查询随后将被添加到包含目录的“唯一真实来源”主题中。
7 个赞
我觉得更合适的做法是制定一个流程，用于将查询打包到数据资源管理器中。
可以创建一个带有 Contribute > Feature 标签的 data-explorer #candidate-query，并附上候选查询。该功能说明应解释为何需要打包，以及其独特性和重要性。
然后我们判断该提议是否有效，若有效则打包查询并关闭该议题。
当然，如果你真的想看，也可以随时浏览那些被拒绝的打包请求。
8 个赞
在数据探索器中扩展原生的查询功能，无疑会对许多管理员和用户提供极大的帮助，并提升其易用性。
不过，我认为同样存在对“二级”查询的需求，以及一个专门讨论这些查询的结构化场所。我来元讨论区是为了寻找解决自身问题的方案，而非单纯为了贡献巧妙的查询。
也许可以将 @sam 和 @Johani 的方法结合起来？创建一个子分类，其中包含一些被标记为“官方”的主题或查询，并将它们与插件捆绑发布。
1 个赞
关于此问题的一个小更新——我们现在有了一个 Data & reporting 类别。
我会回顾一下这个话题中的建议，看看还有没有其他可以借鉴的想法。
5 个赞