您是否愿意雇佣更多人?我想到的几位活跃贡献者,他们会是CDCK的优秀员工。
是的,我们正在招聘——但不是在这里 Meta 上担任版主。一个全职 CM 就足够了。请记住,他才刚刚开始担任这个职位一周,所以需要一些时间来处理所有事情。
一些礼貌性的姿态,仅此而已:
- 每次有人留下 bug-notice 或 feature-request 时,团队都会有人回应
- 在合理的时间内,最多两周,团队会简要通知正在发生什么,或者说明为什么什么都没有发生
就这样。没有必要尝试满足每一个请求,有些请求实际上是浪费时间或太难了,但你不能让事情悬而未决。简单的回应会给人一种印象,即团队正在倾听,甚至关心社区方面发生的事情。
你们经常这样做,我承认。但仍然有太多悬而未决的案例——有些是因为 OP 没有提供更多细节或者干脆消失了,但有些则被团队毫无预兆地放弃了。
这应该与你们的政策有关。我不知道你们是怎么工作的,但当某人被分配任务时,他/她会说几句话。嗯,你知道我的意思 ![]()
否则……没有人能取悦所有人。但你们比我们普通人更处于聚光灯下。例如,这就是为什么像我这样被动攻击的行为与你们的行为不同——你们可以让我沉默,我只能通过离开 Meta 来让你们沉默。
我并不是说团队在说坏话
那只是一个例子,说明你们必须小心。
好吧,我将结束这个话题。团队没有更大的问题,除了几个点赞和几句话可以解决(以及更用户友好的编辑器
说真的——Discourse 需要一个更简约的编辑器,但这完全是另一回事,抱歉……)
—
我们是否也应该针对用户?因为老实说,这里的用户经常比团队本身更麻烦。
我确实花了一些时间来分类这个列表:
https://meta.discourse.org/c/feature/2/none?order=op_likes&status=open
我想知道这里隐藏的一个问题是我们是否应该在 Feature 类别上尝试使用元投票插件。这个类别里的东西往往会被埋没,也许给热门想法更好的可见性会有帮助,然后社区可以帮助(通过改进 OP、增加投票等)提升更多好想法,我们可以强制执行一些规则,即“Discourse 将始终官方回复投票数超过 N 的主题”。
看看这个大水池的大小,我认为我们对所有超过 10 票的都可以给出某种形式的回应,我认为大多数超过 10 票的已经有了员工的回应。然后,如果我们管理好了 10+ 票,我们可以逐步处理 5+ 票,以此类推。
有个东西叫标签 ![]()
抱歉,我忍不住了。但我认为 UX 并不是一个高流量的分类(从我的角度来看,这有点奇怪,因为 UX/UI 是仅次于良好基础代码的最重要部分;不过也没有什么大问题)
但这更多是结构或组织问题,而不是让 Meta 更有趣——轻松找到东西也许算是一种乐趣。但它可以,而且将会让你们的工作更轻松……当然,除非它妨碍了你们的日常生活。
这是一个非常好的主意。
不过,在过去的几周里,我曾考虑建议在那里添加 #install-support 和 #update-support 作为子类别,因为这两个主题有点污染了这个类别,使得“功能支持”主题的突出程度不如它们应得的。
Bug 的工作一点也不好。
我们遇到了一个荒谬的情况,Bug 频道里的任何人都无法
帖子,
因为这会触发 bug_reporter_badge SQL。
答案其实很简单——
- 创建一个由 @team 组成的专门用于授予徽章的小型子集组。
或者…… - 创建一个特殊的徽章,让“用户”在其自己的组中扮演角色,这样团队中的任何人都可以自由地在 Bug 中

更新徽章 SQL,将team从查询中移除。
我正在考虑在这个主题帖中写一篇帖子,解释我目前现实生活中的情况。
我如何决定,在绝望的时候,投身于 Discourse Enthusiast’s Training 是我最好的行动方案,以及像在 Bug 中有几篇帖子被忽略这样愚蠢的事情,对我来说是现实生活中的一个沉重打击。
抱歉,我完全不同意这个观点。我们喜欢收到的 bug,而这个徽章是一个受欢迎的副作用。
这个徽章绝对没有阻碍我点赞 bug。
请随意浏览这个列表,查看过去 30 天的帖子:Bug - Discourse Meta
找出 10 个团队点赞了第一个帖子的例子……以及 10 个团队没有点赞第一个帖子但实际上应该点赞的例子。
幸运的是,我已经在这里当了足够长的“用户”,如果联合创始人如此强调,我就不必浪费时间去做这件事了。
我要去遛狗了。
祝你有美好的一天。
这进入了非生产性区域,将此话题搁置 30 天
感谢大家的贡献,但遗憾的是,这对我来说变得过于激烈和不集中了。
此主题在 26 天后自动开启。
多么有趣的话题。 ![]()
我的感觉是,如果你不喜欢为 Meta 做出贡献,那么它就不适合你。我个人觉得在这里支持其他人解决问题非常有意义。利他主义的解决问题是我的天性。我深知 Discourse 团队有多么忙碌,以及他们为提供支持和服务付出了多少努力。如果你在这个网站上参与了一段时间,那应该很明显。 ![]()
我本人会尝试阅读每一个话题,并至少对每一个未读话题(通过点赞或评论)做出回应,如果它还没有被回应的话。但我来这里的时间不长,实际上是从今年年初才开始的。我喜欢阅读所有的话题,因为这是一个学习的过程。当用户在寻求帮助时遇到负面经历,这确实令人遗憾,我总是会把这当作是针对我个人的,并思考可以改进什么或如何避免这种情况。然而,我认为创建一个话题并用被动攻击性的陈述来攻击团队,似乎与支持任何集体项目或团队所需的尊重、耐心和积极的方法背道而驰。
我见过用户在他们自己的话题下再次发帖寻求帮助,这完全没问题。尽管去顶你自己的话题或再次寻求帮助吧。在我的论坛上,我并不总是能立即帮助用户,如果我因为某种原因没有回应他们的问题,我并不介意他们来烦我或再次询问。我甚至有过用户标记我的帖子来引起我的注意,哈哈,我对此没意见。
另外,@JammyDodger 和 @Canapin 自我来到 Meta 以来,在社区版主的角色上表现出色,他们对我的学习和享受起到了宝贵的作用。谢谢你们 ![]()
为了记录在案,我创建了这个主题。
所以任何批评或反馈都是我邀请的。 ![]()
这是我工作的第三天,我认为这让一些人感到惊讶。
但我发现这次谈话非常有益,无论是好的还是坏的。
一年后回顾它也很有趣。值得注意的是,许多最初的贡献者现在拥有 Team
标识,而他们以前没有。
(@Canapin @keegan @mcwumbly)。我不知道这是否会影响新来者的阅读体验,但如果会的话,可能值得引起注意。
但回到主要观点,我希望我在过去一年里付出了坚实的努力,让 Meta 成为一个愉快的地方,您可以在那里做出贡献并在需要时获得支持。
有很多事情在发生,也有很多事情需要跟上(有时是令人头晕目眩的滔滔不绝
),我意识到我并不完美——但希望,当一切都算在一起时,我能获得一个积极的评分。 ![]()
无论如何,我肯定将此视为一次胜利。
![]()
我怎么会错过这个
![]()
我没有完全重读这个话题,但我认为这里的“贡献”可能比最初预期的要宽泛。寻求帮助是一种有效的贡献方式。因此,最初的问题可以分成几个变体。
-
如何让寻求帮助更有趣?
-
如何让帮助他人更有趣?
-
如何让提供反馈更有趣?
-
如何让与 Discourse 相关的开发更有趣?
等等……
每个问题的答案可能都不同 ![]()
这是一个很好的观点。一个人的动机和在此的原因以及他们的相对观点无疑会影响在此的经历。显然,身处服务器宕机和用户尖叫的关键情况的人,其即时支持需求、期望和心态将与某个无法弄清楚用于自定义侧边栏的代码片段的人(就是我)截然不同。
我同意将这种情况扭转为寻求积极改变的目标。
然而……
对我来说,最突出的两个负面因素,我认为与发帖人的经历相符,一方面是沉默,另一方面是敌意。并不是说一个人总是看到它们,但当一个人确实看到它们时,它们会令人气馁且不受欢迎。
遗憾的是,我认为我最常看到敌意来自非常资深的人,这是一个额外的负面因素。在“敌意”中,我包括那些让我觉得被轻视和居高临下的事情。
我可以想到一些可能的原因,这些原因不一定是性格缺陷:
- 在烦躁或时间紧迫时发表评论
- 看到自己已经看过很多次的东西
- 感觉项目是自己的地盘并做出相应回应
- 简短地说些话,没有意识到它们可能被视为粗鲁或无礼
一方面保持沉默
在浏览和发帖时,只有两件事(只是一点点!)让我困扰。
- 在 Support 中发帖,几天甚至几周都没有回复。
这就是你的意思吗?
我现在试图通过查看未得到回复的帖子来缓解这种情况。
要么尝试运用我的
知识,要么知道我没有答案但会以有意义的方式轻轻地顶起帖子,或者询问团队中是否有人有想法。
不过,我应该更经常这样做。
是的,紧急支持主题没有回复,这在我身上发生过一次。但是,浏览论坛,我感觉有不少没有回复的主题。有你加入并打算处理它们是件好事。