我们对#feature类别启用了投票主题! 🥳

大家认为每个信任级别允许的合理投票数是多少?我看到在 Meta 上,我们将 TL0 的投票数从 2 降至零,TL4 的投票数从 10 降至 8。我注意到我自己也用完了投票数,尽管我在这里是管理员!:rofl:

1 个赞

我一直认为这个数量是故意限制的,这样它就可以作为一种“这对我来说真的很重要”的指标。即使我用完了投票权,我仍然可以喜欢所有请求并将我的用例添加到功能请求中。而且,一旦我投票的另一个功能请求完成并且该主题关闭,我仍然可以对这些主题进行投票。

1 个赞

@tobiaseigen,我不会限制他们……我发现自己从不使用投票,因为对我来说,我只是支持或反对某件事;当点赞存在时,试图确定某件事是否对我来说真的重要并不是一个特别实用的利用我时间的方式。

1 个赞

我将最近的讨论移至 Jammydodger 的原始帖子,因为我觉得在这里继续讨论投票是合适的。

我喜欢限制的想法,但我也认为有太多未解决的功能请求,所以设置一个非常低的限制似乎不公平。我自己也觉得受到限制!投票也是一种信号,如果我们不让人们投票,我们就剥夺了产品团队的信号。

我倾向于在以下方面提高限制。大家觉得怎么样?

信任等级 当前投票数 建议投票数
TL0 0 0
TL1 4 10
TL2 6 20
TL3 8 24
1 个赞

Imo 24 turns this into practically unlimited

I like the current limits, makes you think

2 个赞

我确实想知道,宝贵的投票是否受到严格限制,这是否会导致信息有限。考虑到这里用户数量众多,投票数通常似乎偏低。许多功能建议的点赞数比投票数还多,但我猜只有投票才会被注意到。

总是没有投票,并且总是不得不进行分类和牺牲才能对任何新事物进行投票,这是一个巨大的障碍。我查看我现有的投票以了解如何释放投票……但没有一个请求是不值得的。它们只是从信息流中滚动而过,被遗忘了。

我应该放弃它们吗?

我应该在我的收藏夹中添加评论吗?投票了一个功能后,评论“是的,好主意!”感觉像是多余的混乱。

好主意只有一两个投票。人们没有发现它们,不感兴趣,还是……他们只是没有投票了?:pouring_liquid:

增加限制不需要大量的编码,而且感觉会有帮助——但我也想到拓宽道路以减少交通流量只会吸引更多交通,然后你又回到了原点。

只是随便说说……一些大量的编码功能性更改作为硬性限制的替代方案:

  • 根据 TL 分配每月的投票数。(在“投票日”,人们会访问 Feature 并评估开放项目……)

……或者,正如 heliosurge 提到的,最终释放投票:

  • 在设定的时间后释放已使用的投票,或者
  • 工作人员定期审查过时的功能请求,然后 a) 提升主题以获得另一个机会,或者 b) 评论“无计划解决”并释放投票。

……无论哪种情况,已投的票都将保留,并且用户不能通过进一步取消对这些主题的投票来超过他们的投票分配。

(我说的轻松。这可能需要大量的编码 :grimacing:

1 个赞

@sam,对我来说不是这样,因为我只使用点赞。它目前的实现感觉有点多余——就像 GitHub Discussions 同时存在点赞和竖起大拇指一样。

1 个赞

同意重复点赞会造成混淆

“我喜欢你写功能请求的方式,对我来说听起来不错”

“我认为 Discourse 应该构建这个功能,这绝对是我心中的前八名”

当启用主题投票时,禁用发帖人点赞可能是一个有趣的实验。

1 个赞

有一些关于关闭一些请求的说法,例如“抱歉我们不这样做”。

关闭已完成 2 年的功能,并将不再有任何意义的功能请求标记为过时,这确实非常有说服力。

2 个赞

我认为最终不会有太大变化。我的大部分投票都是在一年前添加的。是的,我本来可以投票给更多的话题,但一旦我用完了所有的投票,结果还是一样:我必须等一个投票完成并关闭,或者我需要从另一个话题中移除我的投票。我相当确定,在 Meta 上也有超过 20 个好的功能请求 :slight_smile:
正如我之前所说,对我来说,投票比“喜欢”更强大。但我仍然认为对第一个帖子的“喜欢”对于吸引兴趣也非常有帮助。在启用投票功能十多年来,它们一直是指标。因此,忽略它们,尤其是在长期存在的请求上,就意味着忽略了用户过去能够表达支持的唯一方式。
另外,也许没有人认为这个功能请求是他们非常需要以至于要花一票去投票,但很多用户喜欢它,因为他们认为它会有帮助。一票(通常由请求的作者投出)是否比多个“喜欢”更能说明这个功能对一系列不同的 Discourse 网站有多大帮助?

我想知道,与其增加“我真的很感兴趣”的投票数量,不如限制他们可以分配话题的数量。
所以,与其今年有 378 个主题可以投票(
Screenshot_20251113_123848_Firefox
),不如考虑预先选择它们。
例如,只有那些获得一定数量反应表明多个用户感兴趣的请求才能投票,或者你可以按时间限制,说投票仅限于某个时间段的主题,以便在该功能组中找到最受欢迎的。
你也可以说,“我们正在审查队列。您会想到哪些请求?”然后将它们移到一个子类别中进行投票。

能够将 4 票投给约 100 个话题,其比例将比能够将 10 票投给所有开放的功能话题要高。

2 个赞

@sam,我希望的是相反的情况。投票在技术上是否提供了点赞所没有的东西?我怀疑没有人会点赞一个他们不支持的“功能请求”。

如果禁用点赞,启用投票,我认为那才会“减少信息量”。作为比较,Forgejo 和 GitLab 不限制点赞可能表明,将点赞作为简单的支持或不支持指标是有价值的。