Jagster
(Jakke Lehtonen)
25
或者也许根本没有要求，这只是一个实际的元话题？
但是。
也许问题在于并非所有人都同意他们被倾听或采取行动？或者有些人感觉他们没有被倾听。行动取决于各种原因，如果给出了原因，用户是否接受取决于他们——但人们就是这样行动的。但“如果”不应该这么多。
来自“官方 Discourse* 的完全免费支持并非如此，但来自社区的支持确实是免费的——而这实际上是 Discourse 获得免费支持；）。这是某种交换经济的一部分。我们可以颠倒过来：参与者完全免费地揭示问题，以便 Discourse 可以将其作为业务。
但对我来说，钱的整个问题真的很无聊。但它不能成为一切的标准答案。
我在这里没有问太多问题。我可以阅读文档和话题，做一些谷歌搜索。我在这里几乎没有遇到什么问题。如果我有，我就会消失。但这并不意味着我完全满意一切，或者自动接受团队/官方——或来自其他用户的——最好的行动方式和——这总是很糟糕——反应。这确实是人类的方式。
在我看来，这个话题或多或少只是要求团队与用户多互动。这意味着，诸如某个东西或错误已被记录但被埋没，因为工作量过大而被遗忘之类的借口，只是一个糟糕的方式。
好吧，请继续。我没有什么可说的了，而且我说的很多都是空洞的元话题，我知道。我将继续找出为什么我无法从 WordPress 将带有斯堪的纳维亚字母的标签发送到 Discourse——这对我来说是一个更相关的问题，而且已经有一段时间了 
1 个赞
Jagster
(Jakke Lehtonen)
26
这也是事实。
我个人不在乎点赞。那些对我来说毫无意义（徽章也是如此）。现在我们处于负面情绪中，或者说我可能处于负面情绪中，这一点真的很好记住：有许多 bug/用户体验/功能请求得到了令人难以置信的快速解决。当结果很重要时，这比点赞的数量更重要。
3 个赞
参与者们揭示问题是因为他们正遭受这些问题的困扰。除了通过软件更改或设置的解决来修复问题并获得他们期望的行为之外，没有任何其他激励措施。
Discourse 主要通过销售托管版本的 Discourse 来盈利，付费客户应该是他们的第一优先。我们正在自托管免费的开源软件。他们也通过回答我们的疑问来帮助我们，我对此非常感激。
用户之间的支持是完全不同的游戏。我尝试回答各种支持请求中的疑问，并尝试重现 bug 报告，因为我希望这些问题得到修复。我没有任何经济或其他方面的激励，除了问题得到修复，而且这可能也会间接帮助到我的一个客户。总的来说，这将使产品更加健壮，整体上更好。
6 个赞
知道了。并已划重点。
很高兴在我不小心做错任何事之前就听到这些。
这些都是非常实际的观点（尤其是徽章那个，因为我现在被提升为团队成员了，我之前没考虑到这一点）。我认为我宁愿我的员工头衔是社区版主（Community Moderator），而不是团队（Team），因为我认为拥有团队头衔确实给了我的一些实际建议一个不应有的权威。我会去打听一下。
7 个赞
我基本同意，但我觉得随着 Discourse 的发展（无论是在受欢迎程度还是复杂性方面），越来越多的人想来了解它是如何工作的。理想情况下，我希望能简化这个过程，让它尽可能地“甜腻”（可以容忍的程度）。人们越早对做 x、y 和 z 感到自信，就越早能分享这些知识并将其传授给下一个新人（以此类推）。
我的贡献可能不像表面上看起来那么无私，因为我通过实践和重复来学习。所以回答关于管理员设置、非 www SSL、升级卡顿等问题，能帮助我比仅仅阅读指南更深入地吸收知识。而且 Discourse 是如此通用和可配置，反映不同人的不同设置，能让我看到一种我以前可能从未考虑过的新使用方式。
所以，至少对我来说，免费支持是互利的。他们希望能得到解决方案，而我希望能学到新东西。双赢。
8 个赞
Tris20
(Tristan)
30
致谢
这个问题存在于每个社区。当你抽象这个问题时，它也适用于一般的生活社交互动。无论你是否喜欢，这篇帖子可能在某种程度上对读者来说不够有价值——尤其是在与他们目前正在处理的其他事情相比时。
我能否让我的主题对我想让人们阅读它的人更有价值？
- 我能删除一些冗余内容吗？
- 图片会有帮助吗？
- 对他们来说，处理这件事真的有益吗，还是会消耗大量他们本可以更好地用于其他地方的资源？
Meta 总体
同意——事实上，这整篇帖子都很好 
理解用户
有一点需要考虑，那就是 Discourse 团队也是用户。
资源
我六月份看的时候，团队大约有 25 人。现在是 64 人。这说明了两件事：
- 他们有很多工作要做
- 他们有很多工作要做
在只有 25 人的时候，他们已经有了成千上万的客户。根据经验，他们为那些付费客户提供了非常非常好的支持。特别是与其他公司相比，尤其是考虑到价格。在过去的一年里，我从团队那里得到了无与伦比的模范支持和互动。特别是 @rishabh 对我们非常有耐心。
Bug 的优先级
付费客户也会遇到 Bug：如果一个 Bug 正在破坏客户的某些基本功能，它就会被优先处理。这在我们的业务中也会发生——最大的客户获得优先权，因为没有他们，我们就无法负担起满足较小客户所需的东西。此外，Bug 的类型起着关键作用：
示例
已发布的页面上的头像带有边框
如果这个 Bug 没有修复会怎样？在一个头像并不那么重要的页面上，头像周围会有一条蓝线。
关于已标记主题和标题更改的权限后门
如果这个 Bug 没有修复会怎样？一个恶意行为者可以立即重新发布被视为机密/不当的内容。如果发生这种情况会怎样？嗯，付费客户现在会面临机密泄露。
贡献就是给予
Meta 上的一切都是免费的。Meta 上所有的一切都是免费的。所有的支持，所有的贡献，所有的社区。我的乐趣在于使用 Discourse 和学习。我通过尽我所能为社区做出贡献来回馈。
每一次贡献都已经通过免费且无限制地使用尖端软件得到了预先奖励。
14 个赞
这是理所当然的。社区支持系统最大的优势就在于此。最好的例子就是人们在 GitHub 上对各种问题和功能请求发表评论。有时，某个功能确实存在，只是我们不知道，因为它没有被广泛使用（或者宣传得不够），有时，错误实际上是功能或保护措施。我们每天都能学到新东西，这是最好的激励。这就是为什么这个话题对我来说没什么意义。这是一个社区，它应该遵循社区精神。
6 个赞
我完全同意。
我认为我希望这个话题能让我和社区里的其他人回应那些觉得它令人沮丧而不是有益的人，看看是否有人有同感，以及看看我们是否可以做些什么来帮助改善这种情况。我不想做任何大的改变。 也许只是更好地宣传元（meta）的积极体验，这些体验让我在这里贡献如此有趣。
我个人觉得到目前为止的回复都很有用。它们巩固了我自己在这里零星贡献时做出的一些假设，但也让我对其中一些有了不同的思考。我希望其他阅读它的人也能觉得它有用（甚至可能鼓励更多的贡献:slightly_smiling_face:
）。
7 个赞
我开了那个话题，但没人回复……但我不希望听起来像个扫兴的人
错误之类的会根据社区的意愿得到修复。鉴于这个社区如此活跃，这没关系。
我只为这款软件以及它是开源的而感到感激——大家做得都很好。
1 个赞
gerhard
(Gerhard Schlager)
36
公平地说，你的帖子是在周五创建的，那时大多数团队成员已经开始享受他们应得的周末了。
而且正如你所注意到的，同一天就有人提出了一个修复方案，因为我们希望改进非 JS 版本，因为它也被用于旧版浏览器。
13 个赞
我将为您提供另一个社区示例。
我是《星际公民》的忠实粉丝和支持者，我运营着一个非常有趣的初创粉丝网站（基于 Discourse 构建！）。
有一个工具供用户提出问题：它被称为“问题委员会”。
这是一个很棒的工具。让用户直接访问问题工具真是太棒了。这并不是游戏和平台完全领先的唯一方式，但它是他们拥有的一个非常复杂的工作流程。
然而，如果我提出一个问题但没有得到任何反馈，我不会生气。我知道 CIG 正在攀登一座多么巨大的山峰，也不指望他们会担心我的虚拟鞋带松了（或者我的问题是什么）。我相信他们知道自己在做什么。他们是游戏界最优秀的团队之一，拥有完全独特的产品和发展方式。
有成千上万的社区问题待解决。这似乎是无止境的。他们有资源来回应每一个问题吗？绝对没有。但他们会做到的。就像 Discourse 一样，它是进化式的软件。一次迈出一到五步。然后是下一组。
而且我是一名支持者！我为认购花费了大量的金钱。
但就像我对 Discourse 及其领先的产品交付方式的尊重一样，我不期望得到任何关注，而且我经常得到比我预期的更多的关注。
每个人都很忙，不可能总是覆盖所有方面。元社区不是付费支持产品。
所以，我的建议是：
- 保持耐心
- 尊重他人的时间
- 如果您没有得到太多关注，请不要感到受伤，带宽是有限的
- 继续贡献，即使人们有时很难回应和承认，它也很可能受到赞赏。
12 个赞
改进之处在于，团队成员应评论任何功能请求。我于 1 月 1 日提出了此请求 – Allow automatic group membership based on subdomain – 但尚未得到回复。即使有人说“不行”或“可能要等一年”，也都可以接受。总比那句通用的（尽管完全合理）“付费或自己动手”要好 
1 个赞
但是支持需要时间和金钱。
您建议的是一个没有付费合同的服务级别协议。这是否过于片面？
我无权置喙，但我并不确定这是否具有商业可行性？
是否可以引入一个全新的客户层级，仅为支持订阅者，在严格的限制内付费以获得增强的支持？考虑到普遍的消费者价格预期，这甚至可能盈利/盈亏平衡吗？
考虑到我们通常在 Marketplace 上看到的预算，我不确定……
元（meta）的部分理念 surely 是“社区支持的支持”，这可以提高参与度，同时降低成本……部分有助于确保一个打包严密且可免费使用的开源产品。
是否所有功能请求都需要回复？我也不确定。如果它们不被删除，它们将对所有人可见，并充当一个开放的待办事项列表。
6 个赞
我确信你是对的。我只是从我的角度回答了如何让为 Meta 做贡献更愉快的问题。也许你会说，提出功能请求不算真正的贡献。这可能也是对的，尽管我确实提出了一个对我来说可行的补丁。总的来说，在这里做贡献是令人愉快的，所以这不是什么大事。
2 个赞
不不，我完全不是那个意思。我见过你的功能请求，你的想法给我留下了深刻的印象。只是我一直没有合适的机会回应。
你的贡献肯定得到了社区的认可。
我唯一的问题是，如果没有正式的业务关系，组织很难做出承诺，即使是针对个人沟通也是如此？
6 个赞
mcwumbly
(Dave McClure)
45
在阅读这次讨论时，我想起了很久以前的另一个话题：Thoughts from the Elm community on Intentional Communication
非常值得一读。演讲也很棒，并且从中可以找到各种相关话题的链接。
不确定这一切如何能具体地回归到这次讨论中，但我现在会再次仔细思考这个问题……
7 个赞
HAWK
(Hawk)
46
我将介入此事，因为我负责管理在这里 Meta 上免费支持你们的团队，以及作为付费客户支持你们的团队。
我已阅读此主题中的每一篇帖子。有些评论是公平的，有些则不恰当。我们非常重视开源社区，它是 Discourse 的基础，但良好的商业运作要求我们优先考虑付费客户。
我们知道，随着我们的发展和业务的繁忙，在这里 Meta 上阅读每一篇帖子变得越来越困难。我们内部对此进行了详尽的讨论。我们最近聘请了 @JammyDodger，这样就有人有时间阅读和回应你们的问题和担忧。我真的不确定我们还能做些什么。
23 个赞
