关于使用 Discourse 管理问题的最佳配置，有哪些建议？

社区
1

今天，我们社区最混乱的部分是我们管理社区问题的方式。为了便于理解，我们运营着一个由公司产品用户组成的产品驱动型社区。问题当然可以指 bug、功能请求或一般性问题——就像 GitHub issue 一样。问题可能来自许多不同的渠道，例如：

  • 我们（我的团队）也负责的 code/tools 的 GitHub issue
  • 我们的开源市场（50 多个且不断增长的 repo/主题）的 GitHub issue
  • 关于我们产品的通用问题/反馈/bug 提交
  • 社区本身内部的问题（社区功能请求等）
  • 其他业务部门提交给我们的内部问题（今天他们通过 Slack 提交）
  • 文档问题

以下是我目前关于如何管理这些问题的一些零散想法，但在此期间，我想看看其他社区是如何做的。那么，你们是如何做的？

  • 这个问题的部分内容是关于我们经典的、永恒的 类别 vs 标签 的组织方式的斗争。
  • 用户通常会被大量的标签选项压垮，可能不知道要搜索哪个标签，或者在大多数情况下根本不尝试添加标签。（强制要求 n 个标签通常会迫使他们付出最少的努力来添加一个标签）。
    • 一个总括性的提交表单可以帮助简化这个提交过程，前提是你们使用了多于 1-2 个类别。
    • Discourse 可以添加的一个强大功能是将标签与 实验性表单模板 中的必需下拉字段关联起来。这样，例如，如果下拉问题是“您正在使用什么浏览器？”，那么与答案 Chrome、Arc 等相关的 Discourse 标签就会出现。
  • 我在这方面最大的问题之一是这个解决方案的“管理视图”。我相信 tickets 插件（尽管截图已损坏，所以我无法回忆起来）可能是一个很好的用例。
    • 在这方面，我确实需要对主题的许多元数据进行操作。提交日期、当前状态、关联标签、分配人、关闭能力等。
8 个赞
2

非常同意。表单模板可以成为 Discourse 中最好的功能之一。甚至还可以添加一个输入框用作主题标题。能够在表单模板中插入/显示图片，对于各种用途来说也将非常方便。

2 个赞
3

同意关于电源的说法。虽然有些离题，但它还需要一个像标准撰写框一样的真正自由格式的文本框选项。

3 个赞
4

您是否考虑过使用 Custom Wizard Plugin :mage:？ bug 报告的示例设置位于 Bug Report - Coöperative

3 个赞
5

我应该提一下：我使用的是 Discourse 企业版，所以我通常需要使用 official plugins，或者开发一个插件/由 CDCK 维护。 :smiley:

4 个赞