Flunes什么时候选 Canny: 公开 roadmap、changelog 和投票计数门户本身就是你要的核心。 你希望有一大批终端用户社区来发帖、给需求投票。 反馈管理放在研发之外，作为一条独立的工作流。
Flunes vs Canny
- 是，原生支持
- 部分，靠增购项
- 否，并非其职责
「部分」指可通过集成或付费增购实现，并非核心模式。
迁移到 Flunes 你能得到什么
你希望反馈直接落成 GitHub issue，也就是开发本来就待着的地方。
你不想去运营和审核一块公开的 roadmap 或投票看板。
给你提反馈的是你自己的 PM、QA、设计师、支持或运维，而不是一大批公开用户。
你不想为提反馈的每个队友付一个席位的钱。
没有看板的一天
用 Canny 时，总得有个人来管这块看板：给进来的帖子分类、合并重复项、回复评论、把状态更新到位。换成 Flunes，这个角色就消失了。团队里的 PM 或测试打开自己的链接，写下哪里出了问题，这条报告就会到达你的仓库，已经打好标签，紧挨着代码。你的开发在 GitHub 里按平时的节奏分流它，就在他们处理 pull request 和 CI 的同一个地方。没人再去开第二个标签页查看某个门户，也没有东西卡在队列里等审核员处理。收集这一步不再是一份工作，而成了队友发反馈时顺带产生的结果。
你刻意放弃的东西
这个 Canny 替代方案是刻意做窄的，所以要把这笔取舍讲清楚。这里没有公开的 roadmap 页面，没有可供用户浏览的 changelog，也没有用来显示哪条需求最受欢迎的投票。如果你靠票数来排优先级，或靠一块可见的看板来跟社区对齐预期，那 Flunes 替代不了这些。它也不在截图上做标注，不会作为一个 widget 挂在你的站点上。提反馈的队友发来的是纯文字加一张可选的图片。收集之后的一切，排优先级、做规划、交付，都在 GitHub 里发生，而不在 Flunes 里。
谁该做这个切换
如果你的提反馈者是你自己的人，PM、QA 测试、设计师、支持或运维，而你真正的目标是把他们的意见送进 GitHub、又不想背上运营一个产品的开销，那就切过来。如果你之前给 Canny 付费、买的却是一块你几乎不去审核的看板，或者你真正在意的反馈其实来自内部、却在按追踪的终端用户数付费，那也切过来。如果一个由投票驱动的公开 roadmap 确实是你和一大批用户沟通方式的一部分，或者反馈管理本就是研发之外一项独立的职能，那就留在 Canny。当看板从来都不是重点、而 GitHub 早已是重点时，Flunes 才更合适。
常见问题
不能，而且这是故意的。Flunes 不提供公开 roadmap、changelog 门户或投票计数。如果你的目标是把团队的反馈干净地送进 GitHub、又不想运营一块看板，那 Flunes 更合适。Canny 专注于面向外部用户群的公开投票门户；Flunes 专注于把队友的报告送进 GitHub。