您是否愿意雇佣更多人？我想到的几位活跃贡献者，他们会是CDCK的优秀员工。
1 个赞
是的，我们正在招聘——但不是在这里 Meta 上担任版主。一个全职 CM 就足够了。请记住，他才刚刚开始担任这个职位一周，所以需要一些时间来处理所有事情。
10 个赞
一些礼貌性的姿态，仅此而已：
- 每次有人留下 bug-notice 或 feature-request 时，团队都会有人回应
- 在合理的时间内，最多两周，团队会简要通知正在发生什么，或者说明为什么什么都没有发生
就这样。没有必要尝试满足每一个请求，有些请求实际上是浪费时间或太难了，但你不能让事情悬而未决。简单的回应会给人一种印象，即团队正在倾听，甚至关心社区方面发生的事情。
你们经常这样做，我承认。但仍然有太多悬而未决的案例——有些是因为 OP 没有提供更多细节或者干脆消失了，但有些则被团队毫无预兆地放弃了。
这应该与你们的政策有关。我不知道你们是怎么工作的，但当某人被分配任务时，他/她会说几句话。嗯，你知道我的意思 
否则……没有人能取悦所有人。但你们比我们普通人更处于聚光灯下。例如，这就是为什么像我这样被动攻击的行为与你们的行为不同——你们可以让我沉默，我只能通过离开 Meta 来让你们沉默。
我并不是说团队在说坏话 
那只是一个例子，说明你们必须小心。
好吧，我将结束这个话题。团队没有更大的问题，除了几个点赞和几句话可以解决（以及更用户友好的编辑器 说真的——Discourse 需要一个更简约的编辑器，但这完全是另一回事，抱歉……）
—
我们是否也应该针对用户？因为老实说，这里的用户经常比团队本身更麻烦。
4 个赞
我确实会花一些时间来整理这份列表：
https://meta.discourse.org/c/feature/2/none?order=op_likes&status=open
我在想，这里可能存在一个隐藏的问题：我们是否应该在 meta 的 Contribute > Feature 板块中尝试使用投票插件？内容在这个板块里容易被淹没，如果能让热门想法获得更好的曝光，或许会有所帮助。这样社区就能帮忙把更多好想法推上去（比如完善原帖、增加投票等），我们也可以制定一些规则，比如“Discourse 官方将对获得超过 N 票的话题做出正式回应”。
考虑到这个“大池子”的规模，我认为对获得 10+ 票的内容给出某种形式的回应是切实可行的。我觉得大多数获得 10+ 票的话题已经有工作人员回复了。如果我们能处理好 10+ 票的情况，接下来可以逐步扩展到 5+ 票，依此类推。
此外，我觉得 Contribute > UX 板块格外棘手，因为它介于 Contribute > Feature 和 Contribute > Bug 之间。我在想这个板块究竟是起到了帮助作用，还是反而造成了阻碍？
不过，Support 板块运作得非常出色，Contribute > Bug 板块在我看来也是如此。
20 个赞
有个东西叫标签 
抱歉，我没忍住诱惑。但我认为 Contribute > UX 这个分类的帖子量并不高（而且在我看来有点奇怪，因为 UX/UI 是在良好基础代码之后最重要的部分；不过目前并没有出现更大的问题）
但这更多是关于结构或组织的问题，而不是让 Meta 变得更有趣——轻松找到东西或许也算是一种乐趣。但这确实能让你的工作更轻松……除非它妨碍了你的日常生活，当然。
3 个赞
这是一个非常好的主意。
不过，在过去的几周里，我曾考虑建议在那里添加 #install-support 和 #update-support 作为子类别，因为这两个主题有点污染了这个类别，使得“功能支持”主题的突出程度不如它们应得的。
8 个赞
Contribute > Bug 频道完全无法正常工作。
我们面临着一种荒谬的情况：@team 中的任何人都不能对 Contribute > Bug 中的帖子点赞 
，因为这会触发 bug_reporter_badge 的 SQL 逻辑。
解决方案其实很简单：
- 创建一个专门用于授予徽章的 @team 小型子组。
或者…… - 创建一个特殊的徽章，允许在专属组中模拟“用户”身份，这样团队中的任何人都可以在 Contribute > Bug 中自由点赞 。
更新徽章的 SQL 查询，将team排除在外。
我正在考虑在这个主题中写一篇文章，解释我目前生活中的真实情况。
我是如何在绝望时期决定投身于 Discourse Enthusiast 的培训作为最佳行动方案的，以及像 Contribute > Bug 中的帖子被忽视这样愚蠢的事情，是如何成为现实生活中的沉重打击的。
抱歉，我完全不同意这个观点。我们欢迎各种漏洞报告的提交，而徽章只是一个令人愉快的副作用。
这个徽章绝对没有阻碍我去给漏洞报告点赞。
你可以查看过去 30 天的这份列表：Bug - Discourse Meta
找出 10 个团队给首帖点赞的案例……再找出 10 个团队没有给首帖点赞但本应点赞的案例。
10 个赞
幸运的是，我已经在这里当了足够长的“用户”，如果联合创始人如此强调，我就不必浪费时间去做这件事了。
我要去遛狗了。
祝你有美好的一天。
这进入了非生产性区域，将此话题搁置 30 天
感谢大家的贡献，但遗憾的是，这对我来说变得过于激烈和不集中了。
19 个赞
此主题在 26 天后自动开启。
多么有趣的话题。 
我的感觉是，如果你不喜欢为 Meta 做出贡献，那么它就不适合你。我个人觉得在这里支持其他人解决问题非常有意义。利他主义的解决问题是我的天性。我深知 Discourse 团队有多么忙碌，以及他们为提供支持和服务付出了多少努力。如果你在这个网站上参与了一段时间，那应该很明显。 
我本人会尝试阅读每一个话题，并至少对每一个未读话题（通过点赞或评论）做出回应，如果它还没有被回应的话。但我来这里的时间不长，实际上是从今年年初才开始的。我喜欢阅读所有的话题，因为这是一个学习的过程。当用户在寻求帮助时遇到负面经历，这确实令人遗憾，我总是会把这当作是针对我个人的，并思考可以改进什么或如何避免这种情况。然而，我认为创建一个话题并用被动攻击性的陈述来攻击团队，似乎与支持任何集体项目或团队所需的尊重、耐心和积极的方法背道而驰。
我见过用户在他们自己的话题下再次发帖寻求帮助，这完全没问题。尽管去顶你自己的话题或再次寻求帮助吧。在我的论坛上，我并不总是能立即帮助用户，如果我因为某种原因没有回应他们的问题，我并不介意他们来烦我或再次询问。我甚至有过用户标记我的帖子来引起我的注意，哈哈，我对此没意见。
另外，@JammyDodger 和 @Canapin 自我来到 Meta 以来，在社区版主的角色上表现出色，他们对我的学习和享受起到了宝贵的作用。谢谢你们
9 个赞
在此说明，这个帖子是我开的。
所以任何批评或反馈都是在我邀请下的结果。
那是我入职的第三天，我想这确实让一些人感到意外。 但实际上，我觉得这次对话非常有价值，无论好坏。
一年后再回头看，也很有趣。值得注意的是，当初的一些原始贡献者现在都拥有了团队标识 
，而以前并没有。:)(@Canapin @keegan @mcwumbly)。我不知道这是否会影响新来者的阅读体验，但如果有的话，提一下或许值得注意。
回到主要话题，我希望在过去的一年里，我付出了扎实的努力，让 Meta 成为一个令人愉快的贡献场所，并在你需要时获得支持。
这里的事情很多，要跟进的东西也很多（有时简直是让人大脑融化的信息洪流 
），我也意识到我并不完美——但 hopefully，当所有事情都算总账时，我能获得一个正面的评价。
无论如何，我肯定把这视为一次胜利。:)
11 个赞
我怎么会错过这个
4 个赞
我没有完全重读这个话题，但我认为这里的“贡献”可能比最初预期的要宽泛。寻求帮助是一种有效的贡献方式。因此，最初的问题可以分成几个变体。
-
如何让寻求帮助更有趣？
-
如何让帮助他人更有趣？
-
如何让提供反馈更有趣？
-
如何让与 Discourse 相关的开发更有趣？
等等……
每个问题的答案可能都不同
5 个赞
这是一个很好的观点。一个人的动机和在此的原因以及他们的相对观点无疑会影响在此的经历。显然，身处服务器宕机和用户尖叫的关键情况的人，其即时支持需求、期望和心态将与某个无法弄清楚用于自定义侧边栏的代码片段的人（就是我）截然不同。
4 个赞
我同意将这种情况扭转为寻求积极改变的目标。
然而……
对我来说，最突出的两个负面因素，我认为与发帖人的经历相符，一方面是沉默，另一方面是敌意。并不是说一个人总是看到它们，但当一个人确实看到它们时，它们会令人气馁且不受欢迎。
遗憾的是，我认为我最常看到敌意来自非常资深的人，这是一个额外的负面因素。在“敌意”中，我包括那些让我觉得被轻视和居高临下的事情。
我可以想到一些可能的原因，这些原因不一定是性格缺陷：
- 在烦躁或时间紧迫时发表评论
- 看到自己已经看过很多次的东西
- 感觉项目是自己的地盘并做出相应回应
- 简短地说些话，没有意识到它们可能被视为粗鲁或无礼
10 个赞
这就是你的意思吗？
我现在试图通过查看未得到回复的帖子来缓解这种情况。
要么尝试运用我的 
知识，要么知道我没有答案但会以有意义的方式轻轻地顶起帖子，或者询问团队中是否有人有想法。
不过，我应该更经常这样做。
4 个赞
是的，紧急支持主题没有回复，这在我身上发生过一次。但是，浏览论坛，我感觉有不少没有回复的主题。有你加入并打算处理它们是件好事。
4 个赞