这正是 discourse 文档的问题所在。
尽管对某些人来说，“搜寻”主题是可以的，但这并非文档。这意味着用户，甚至更糟的是管理员/版主，都必须搜寻信息。
不，它不是。这一直是，而且仍然是 Discourse 最大的不足之处。我不知道我现在是不是太粗鲁了，但这里的倾向是过于以开发者为中心——如果你不知道，你总可以在 GitHub 上阅读源代码。CDCK 没有太大的动力去为用户（当然也包括管理员）构建良好的文档，因为他们的目标是大型托管公司。所以对他们来说，最低水平加上社区帮助对于“搭便车的人”（他们做了大部分的 bug 查找和用户体验建议 
）来说就足够了。除非我们那时需要更自由地使用标签……
足够了 不仅仅是笔误或低水平的英语技能。CDCK/团队已经开始构建更好的文档，我完全相信，过一段时间后，像这样的侧面话题只会是过去的残响。
4 个赞
就开发者/用户社区而言，Discourse 的水平远高于平均水平。错误似乎能被快速修正，功能请求也不会被忽视，尤其是当它们有合理的用例时。而且，在线工作人员（付费或志愿者，我不太确定如何区分）在指导我们这些新手方面做得相当不错，而且很有耐心。
是的，文档需要改进，但编写好的文档既昂贵又耗时。此外，开发者通常写不出好的文档，因为他们离产品太近了，他们无法像用户那样看待它。过于接近代码也是一个产品测试问题，尽管在许多开源项目中，用户社区在测试方面做得很好。
5 个赞
当然是这样。编写高质量的代码也是如此。高质量的人力工作往往成本高昂。但代码和文档是捆绑在一起的，文档在没有人去做的时候才变得昂贵。否则，它就像编码、测试、设计、用户体验/用户界面等一样，是产品至关重要的组成部分。但开发人员通常讨厌文档，因为他们就是讨厌做这件事，里面没有什么吸引人的地方，而且他们通常在这方面很糟糕 但由于公司的所有者和其他主管也是开发人员，他们根本不在乎那些人只是挑选他们想做的事情，而不做其他事情。
但现在我扯得太远了，离题太远了。所以我要走了，指向#documentation，因为它现在正在发展。
1 个赞
我完全同意这一点。我是一名拥有 20 多年经验的开发人员，尽管我近年来已转向平台工程。
当你寻求建议时，这一点就非常清楚了，开发人员（我猜的？我只能看到他们在标题中是 discourse 本身的一部分）会告诉你，他们之所以这样做是因为他们决定了，所以不会这样做。
此处跑题
我已经说过：在技术栈上坚持己见与在产品上坚持己见是有区别的。你的产品应该满足用户的用例，在合理的范围内，而不是“我的球，如果别人不喜欢，他们可以去别处”。
我已经开始了 5 个新项目，谢天谢地，我们社区里有人对 Ruby 有点了解，他们将在未来几天解释 discourse 的一些基本流程，以便我们开始编写一些插件来提供我们需要的功能。其中最重要的是，让分类版主不再是个笑话。
Users are receiving emails even when everything is set up to not send email notifications 的支持主题已经发展了一些，所以我将其拆分到其他类别中的几个新主题中，让每个主题都有一些发展空间。 
2 个赞
我能想到一个开源项目，其开发人员倾向于做他们感兴趣的事情，而不是做可能让该产品用户的生活更轻松的事情。用例总是一个视角问题，产品用户对用例的看法与开发人员不同。开发人员倾向于将用户所做的事情视为“只是更多的数据”，并且常常看不到一个小小的改动可能会对可用性产生巨大的影响。（我参与过不少系统开发，而且我敢肯定我有时也有过这种态度。）
到目前为止，我不能说我在 Discourse 开发中看到了那种态度，但我才来了一个月。
至于离产品太近，我目前正在学习一本关于 Ruby 开发的书中的练习，昨天一个简单的“hello world”应用程序花了我 3 个小时才运行起来，主要是因为这本书假设我熟悉 AWS IDE（cloud9）环境，而我还没有，所以我点击某个东西，它就会撤销我刚刚花了 10 分钟输入所做的更改。
然后，在浏览器中显示工作应用程序的预览时出现了一个问题，这似乎是由于自上次更新书籍以来 Firefox 和 Chrome 在其浏览器中设置的安全限制。经过大约一个小时的网络搜索解决方案，将我的笔记本电脑和台式机的 IP 地址列入白名单起作用了，尽管我仍然需要多走一步才能显示预览。
1 个赞