在过去三周里，我报告/确认了三个尽管是小错误——但没有得到团队成员已阅读帖子的任何确认……
不过他们会很快编辑我那些讽刺的GIF……
我曾考虑过关注 https://meta.discourse.org/t/discourse-support-training-program/194057/1 ……设置一个沙盒，也尝试过本地安装，提出问题，试图提供帮助……但这已经耗尽了我所有的热情。
14 个赞
我将把这个内容移到一个单独的 Site feedback 主题中，这样我们就可以自由地讨论它，而不必担心跑题。
希望您不介意。
我不知道您是否会把我正式视为“团队”的一员，但我已经读过了。
虽然我认为我在留下一些“点赞”和确认方面可以做得更好。我相信其他团队成员也读过了，但如果没有留下一些表示已读的痕迹，看起来确实会像没人 listened。
读到这个我真的很伤心。我非常喜欢 Discourse Experts 项目，我认为这是我能找到这份工作的主要原因之一。 如果您对此感兴趣，我绝对会推荐它，如果您想联系我并提出任何问题，我很乐意成为您的入职伙伴。
其他人也非常乐于助人（对我来说很幸运，因为他们比我懂得多得多:slightly_smiling_face:）
我刚开始担任 Meta 的新社区版主，所以我非常关注如何让更多人觉得加入和贡献（无论是作为专家项目的一部分还是其他方式）是很有趣和有益的。帮助他人解决问题、重现 bug 等需要花费大量时间和精力，我认为人们感到自己的贡献受到重视非常重要。
考虑到这一点，您有什么建议可以让我做得不同，以使其成为一种更愉快的体验吗？
23 个赞
恭喜您加入团队。
我相信这发生在你开始之前。
另外，感谢您慷慨地提出担任我的“入职伙伴”。
请在七年后继续保持您现在的友好……如果有人花时间报告或重现错误或提供任何反馈……至少点击 
因为……
差不多……这确实看起来没有人倾听。
11 个赞
我会努力保持这份友好。 我也一定会确保留下一些‘东西’来表明我们在倾听。从另一方面来说，我确实体会到，花时间贡献一些东西，却似乎石沉大海，这种感觉并不好。但我向你保证，团队确实阅读了所有内容（这听起来有点夸张，但事实并非如此）。
没问题。希望你会接受我的提议。
11 个赞
为了说清楚，动图编辑是一项自动化的工作，它会将远程图片下载到本地存储，这样当远程网站消失时我们就不会丢失图片，而不是由工作人员手动完成。
13 个赞
你好 Falco，
不，那不是我的意思，而且我知道，谢谢。
codinghorror - 19小时前
编辑/移除了我帖子中的一个 gif
猜他认为我不是“失败者” 
完全是手动完成的。
只是说清楚。
5 个赞
我非常喜欢 Discourse，我进行过三次迁移，我浏览过 meta，并且过去在 Marketplace 上成功完成过几项工作。
只有两件事（只是有点！）在浏览和发帖时困扰我。
-
在 Support 中发帖，几天或几周都没有回复。但这很正常，有时人们没有解决方案，或者没有时间，或者不愿意免费提供帮助。它本质上有点令人沮丧，并且不是 Discourse 特有的
-
在 UX 或 Feature 中提出建议，当一个话题获得回复和/或点赞（尤其是来自有影响力的成员或官方 Discourse 开发者的点赞）并获得一些关注时，却没有得到任何形式的后续。然后我就会想，这些想法/建议去哪儿了？
开发团队是否有某种工作文档，将“有趣”的想法记录下来/收藏起来，然后留待以后考虑？其中一些想法是否在未告知作者的情况下就被丢弃了？其中一些是否被列为低优先级，将来可能被添加，但我们在这个阶段根本不知道？
我理解许多原因导致这些话题没有后续，但是，这仍然有点令人沮丧，因为当人们提出建议时，（通常）是因为他们关心并认为这些建议可以为 Discourse 增加价值。
12 个赞
如果你觉得好受些，我为 Discourse 工作，有些任务我分配给自己，但一年或更长时间都没能完成。我们现在有数千名客户，需要优先处理他们的错误/功能/请求，以继续作为一家企业运营。
此外，Chrome 和 Safari 还有一些我一直在等待的公开错误报告，这些报告早在 10 年前就已开立……而这些公司比我们大 1000 倍。拥有一个永恒的待办事项列表，可以说是软件开发的本质。
请记住，Meta 是我们免费提供的产品的免费支持。如果某件事对你来说极其重要，引起我们注意的最佳方式是成为付费客户，或者自己提交 PR 来实现它（或为此付费给承包商）。有些人可以理解地做不到这一点，在这种情况下，最有价值的是要有极大的耐心。
大多数时候我们不知道。也许我们一个月后就能处理，也许要一年！我们规划了一些重要的优先事项，而较小的功能/任务会在有机会时被拾取。也许这是没有人感兴趣的事情，它就会随风而逝。
我们确实希望在 Meta 上回复更多帖子，正如 @JammyDodger 所提到的，这就是我们聘请他作为这里的版主的原因……这是我们第一次有专门负责 Meta 的员工！
27 个赞
你只需要点击 ，我指的是仅仅是承认时间和精力以及存在。
但我真的不想再卷入这件事了……我在这里经历了一系列糟糕的经历，这似乎又增加了。
不过，团队防守很棒。
4 个赞
我将补充一点，使为 Meta 做出贡献更加愉快的是回馈我们所学到的东西。
我想我们大多数人最初都是带着问题、建议来到这里的……然后得到了帮助和回复。我们了解了 Discourse、在线社区、编程……
正如我常说的，我根本不是什么编程大师，但多年来有很多人帮助过我，作为回报，我尽我所能帮助 Support 中的其他人。我的能力很有限，但有时，有限的能力也足以帮助到别人。
提出用户体验改进、新功能、报告错误等也是回馈社区他们曾给予我们的东西的一种方式。
15 个赞
这正是我当时在做的……但这是一厢情愿
6 个赞
我不是 Discourse 团队的一员，但我确实为 Discourse 开发主题组件/插件。
我可以肯定地说，我非常感谢错误报告以及人们花时间来提交这些报告，因为它们非常有帮助。有时我会被其他工作压得喘不过气来，没有时间立即回复，所以我通常习惯于收藏帖子，并设置提醒，以便在有更多时间时查看。
事实上，看起来我收藏了一个关于你在我的复制帖子组件上的报告
也许，收藏并设置提醒可以成为更多人可以使用的技巧？
我确实需要养成 报告的习惯。感谢您的反馈！
15 个赞
我很确定大多数用户并没有使用 Discourse 提供的所有功能，而这可以让体验更加愉快。
我知道书签功能（嘿，我已经完成了 Discobot 的教程…… 
），它很棒，但我真的从没想过要用它。
但我感觉我有点离题了——一个坏习惯，抱歉……
9 个赞
如果我没理解错的话，@geoff777，你的话题主要围绕着你是否得到其他用户和/或工作人员的认可/承认？话题被拆分了，所以你可能还没有具体决定它到底是什么。
但我认为我理解你的感受。
因为很久以前（而且持续了很长时间）我刚开始工作时，我只是一个项目经理的承包商。他几乎是唯一与客户沟通的人，我基本上只是按照指导方针编写代码。
只有当工作不如预期好或者出现问题时，我才会得到反馈。
如果工作足够好，客户满意，我根本得不到任何反馈。
过了一段时间，我因为得不到对良好工作的认可而感到难过，于是我与我共事的人（我非常熟悉他）谈了谈，我说我希望得到更多的考虑，不仅仅是坏的反馈，如果我的工作做得好，也希望得到积极的反馈。这会激励我更多。
他这样做了一段时间，但最终情况又回到了以前。我学会了接受沉默——没有反馈——意味着我的工作做得很好。
但你这里的问题不同，因为我同意如今，点击一下“赞”按钮确实是积极的反馈、认可、承认、分享信念等等。
那么，也许根本问题是：为什么你的帖子没有得到你期望的认可？
我个人来说，与其讨论个人问题，我更感兴趣的是一个像标题所说的那样的话题：“如何让为 meta 做贡献更有趣？”，但要普遍化。
除了我发布的一些小东西，我也说不出更多了，我对 meta 没有什么真正的问题。
我猜当一个人对功能和用户体验提出建议时，他们通常认为自己的想法至少非常方便，最多是超级棒。比如“为什么没有人早点想到这个？”我们都有偏见，我们都想认为自己很聪明，更了解别人的需求，我们想到的事情并不难实现，而且最终每个人都会鼓掌……我对此非常 guilty（并且意识到了！）。
起初，我很高兴看到一些点赞和 Osioke 非常积极的回复 这里，例如。但我对最终缺乏关注度感到失望（话题似乎“被遗忘在历史中”，用你的话来说），尽管我确信我的想法在论坛的背景下是顶尖的、富有创意的，因为我过去曾多次遇到这个图片搜索问题。
但在现实世界中，情况不一定如此。也许在论坛中搜索特定图片的使用场景太小众了。也许实现起来非常困难。也许有大量更重要的事情要做，与 Discourse 相关。也许 [插入十几个缺乏关注度的原因]。
我还检查了 Discourse 的直接竞争对手（Flarum、nodeBB），看看他们是否有类似的功能（他们没有），并查看了 Discourse 的 repo，看看结果摘要是如何生成的，以便稍微了解它是如何工作的（显然我几乎什么都没懂……
）。
从这个意义上说，我并没有享受对我认为很棒的贡献缺乏反馈。
但在这个特定的问题上，那是我个人的问题，而不是普遍问题。
14 个赞
您好 Canapin，
感谢您分享您的经历。
您描述的客户 - 承包商 - 编码员的情况听起来很典型。
承包商糟糕的人员管理。长期只有负面反馈会侵蚀人心。
我在这里与任何用户或个人都没有问题。
事实上，恰恰相反，这里有很多我敬佩其贡献的人。
我将确保我更频繁地发送 ，不仅在这里，而且在我经常访问的网站上。
这里有一些很棒的贡献，人们花费大量时间进行研究、提供链接、代码片段，甚至提供包含输入字段的帖子，这些帖子可以生成用户特定的代码供复制。向他们展示一些 ，这是应得的。
我从团队那里得到了不同的反应。
有些人给予了支持。
其他人则认为这是行业标准，要忽略……通常是多年……这是免费的——闭嘴……我们已经尽力了……我们有成千上万的付费客户……并且通过私信……这里没什么可看的……一切都很完美……如果您想在未来做出贡献……回到您的位置，好好表现。
“点赞”的去向很有趣。
我认为，如果 JammyDodger 早一个月被雇佣，我的贡献可能会得到承认。
也许问题就解决了？
7 个赞
我确实在祈祷。
我发现@osioke给我们的支持爱好者培训链接对于了解影响优先级列表的因素很有用。特别是“三倍法则”在你意识到它的存在时会经常出现。
11 个赞
我同意 Discourse 团队有时会显得有些“团队防御”，而且我认为这在很大程度上是不必要的。但在此也提供一些其他反馈：我其实很喜欢 Meta 是一个不仅仅由专职社区经理运营的社区。拥有一个几乎所有参与工作和做决定的人都是活跃社区成员的社区似乎很少见。这可能意味着他们没有时间回应所有事情。至少对我来说，我总体上更乐于接受这种情况，而不是我所认为最常见的替代方案：社区经理承认你的贡献并表现得非常友好，但他们只能说他们已将其转交给负责的团队。
嗯，可能存在一个折衷方案，我希望这里的团队能找到它。也许可以更好地沟通团队成员是谁，以及他们如何参与社区？在 Bug 这个特定类别中，也许可以改变 Bug-Reporter 徽章的工作方式？团队在最初的点赞方面很吝啬，这可能是负责任的
15 个赞
我完全不贡献，所以这个话题可能不适合我。但总的来说，这里的绝大多数用户都知道这一切。
这里有一个等级森严的社区，这是应该的。有点像英国社会。有些人是资深开发者，有些人更像是最终用户，但他们试图提供一个讨论平台。
这两类人讨论、实施事物以及普遍理解事物的方式截然不同。
对 Meta 来说，成为一个全球性社区也并非易事。我有点奇怪，作为一个芬兰人，我不在乎美式浮夸。我只关心事情本身。而另一些人可能会把直率的言辞视为一种侮辱。
然后事情本身就基本被忽略了，什么也无法推进。即使双方都同意某个问题或困难。
语言障碍也是一个巨大的障碍，或者至少是一个风险。我用芬兰语表达方式说一口流利的皮钦英语，而且我不掌握介词的基本用法。不过我能流利地阅读英语。很容易被误解，同时帮助他人，或者完全参与其中，门槛就更高了。这没有解决办法，但这解释了为什么不是每个人都能参与。
有一个困扰所有开发者论坛的根本性问题。开发者为自己开发，因此难以理解普通用户的需求、反应和愿望。
Meta 绝不是最糟糕的例子，但这里也能看到类似的气氛。那该怎么办呢？我想，什么也做不了。这源于一个截然不同的世界。
必须对 Bug 报告等做出回应。在大多数情况下，人们会做出反应。但必须有一个后续系统，让你稍后能知道一个愿望或错误是能快速修复，还是能在不久的将来修复，或者是不切实际的。功能需求也是如此。
就像人们阅读方式不同一样，写作风格也不同。一些与 Methane 相关的内容非常阳光。一些则简短，有时甚至在芬兰人看来很枯燥。但我不必要地经常看到，如果普通用户拒绝屈服于开发者的意愿，就会出现明显的被动攻击。
当然，用户也有问题。而技术问题的不同能力也无济于事。此外，相当多的明显支持请求属于 FAQ 材料，而且很明显，甚至连基本说明都没有阅读。
工作人员大多数时候都能提供帮助，这是值得称赞的。我自己可能没有那么有耐心。
但我有一个请求。永远不要说某事不发生是因为 Discourse 是免费的。事实并非如此，而且这是一个严重贬低社区的说法。没有社区，你就没有可以令人信服地卖给企业客户的平台。那些维护免费论坛的人，通过持续的测试来支付使用费用。同时，其中一些人，拥有足够的技术技能和必要的语言技能，承担了属于公司的许多支持活动。
同样重要的是要记住，付费客户会得到优先服务，并根据他们的意愿行事。当然，如果你想明确区分 A 类和 B 类用户，那是一种可行的政策。
我们每个人都知道经济现实。但不必像湿抹布一样挥舞到脸上。换一种说法。资源不足、匆忙就足够了。
抱歉，我无法建设性地回应这个标题。也许如果我们都能试着理解他人的需求，找到一些共同点，并达成一个结合 Discourse 的商业、社区活动和 Meta 内容的共识，会有所帮助。
15 个赞
我很遗憾地说，我对这个话题有非常强烈的反对意见。我一直在不带偏见地阅读，试图理解所提出的要求。首先，任何在元社区（meta）待上几天以上的人，基本上都是因为他们喜欢这里的氛围，并试图成为围绕产品（即 Discourse）的社区的一部分。元社区不是一个社交网络或支持小组，不需要把参与过程搞得那么“糖衣炮弹”。
有时我也会犯错，被其他 Discourse 用户或 Discourse 员工纠正我的错误假设或方法。这些纠正有时听起来可能很生硬，但我理解每个人都有自己的沟通方式，因此，人们会试图表达自己的观点，而不是让你感到受欢迎。然而，因为我喜欢使用 Discourse，并想在业余时间为 Discourse 社区做出贡献，这种行为从未阻止我参与元社区。
事实是，无论元社区变得多么“糖衣炮弹”，点赞和回复的数量始终是衡量信息相关性的有力指标。有时，支持帖子的发帖人会完全忽略提供的帮助材料，而是发布自己的评论（例如，我做了这个，然后做了上面提到的那个，这就解决了我的问题），然后他们将自己的评论标记为解决方案。这种行为本身就足够令人沮丧，以至于人们可能会对此有复杂的感受，尤其是那些试图帮助他们但被用户忽略了的人。我完全理解，有时用户确实采取了与建议完全不同的方法来解决他们的问题，但大多数情况下，他们实际上是通过遵循别人的建议解决了问题，然后将自己的回复标记为解决方案，这是否表明用户固执地不愿承认别人帮助了他们？
我看到的另一个问题是，有时帖子几天都没有得到回应。虽然如果支持是付费选项，这会是一个很大的打击，但 Discourse 团队已经足够慷慨，愿意倾听我们的声音并采取行动，而且在元社区提供的支持是完全免费的。我不期望我的 bug 报告或功能请求会疯狂地爆发并创下点赞和评论数量的记录等。如果一个请求或报告是真实的，它会在时间允许的情况下被包含进来，而且我们总可以选择成为付费客户，从而以更快的速度获得团队的关注。
总而言之，我并不抵制任何包容性的行为，但说实话，即使元社区的每一个用户都试图鼓励新的贡献，那些要离开的人还是会离开，那些喜欢留在这里的人还是会留下。所以，这样做的意义何在？
12 个赞
我本可以自己写出来，Jakke。\n（除了我是荷兰人而不是芬兰人，但荷兰人至少一样直接）。\n\n而且你确实做出了贡献。\n\n我对这件事的看法是：\n\n是的，有时缺乏反馈确实会让人有点沮丧。但另一方面，我有很多例子，我发现了一个 bug，它甚至在我检查我是否在帖子中获得点赞之前就被解决了并合并了。\n\n虽然一个健康的社区是优秀开源产品的重要条件，但它不是最终的目标：目标是产品。当我将这个社区与其他任何开源产品进行比较时，我认为它可能是最好的社区。大多数其他开源产品拥有比这更不活跃或更不连贯的社区，如果它们有社区的话。\n\n是的，有时会有一种叫做“团队防御”的东西。但还有其他开源产品因为社区贡献出色而雇佣了这么多人吗？
12 个赞