Bug 与建议迷你应用：社区功能投票、问题反馈与路线图追踪

介绍 Telegram 的 Bug 与建议迷你应用：如何搜索已有反馈、投票、撰写可执行的报告，并区分它与客服、自动限制申诉和群组求助的适用场景，说明状态与投票的真实含义。

内容导读

有一个地方可以报告 Bug 或提出功能请求，而且它不是客服队列：这是一个应用，里面有所有已报告内容的可搜索列表，每条都有投票，并附带状态。

对于一小类问题来说，它是正确的去处；而对于人们最常带到这里的问题来说，它完全是错误的地方。

一个带投票和状态的列表——这与一个写着你名字的队列是两回事。

先搜索，而且要当真

检查是否已有报告这条指示听起来像是例行公事，实际上却是你能做的最有用的事。为已经列出的内容再建一条，并不会给请求增加分量——反而会把它拆散，于是你想要的东西现在有了两堆各占一半的投票，而不是一个足够有说服力的整体。

这也改变了你找到已有报告时该怎么做。给已有报告投票比自己写一份动作更小，效果却明显更好；而添加一条评论描述你这个具体版本的问题，比这两者都更有用，因为它给读到它的人提供了第二组可供复现的情况。

搜索本身需要一点练习。报告会按作者使用的词归档，而那些词很少是你本来会用的词，所以在断定没人提过之前，值得试试功能名称、症状，以及出问题时你正在做的事。

投票是一种信号，不是队列位置 这里的数字描述的是有多少人想要某个东西。它们不是承诺、不是工作顺序，也不是日期——而状态为“已计划”的报告只是被确认了，并非被排期了。

对比

把问题发到错误的地方，多半只是让你等得更久。

	它的用途	会发生什么	它不会做什么
Bug 与建议	应用做了错误的事，或者没做你想要它做的事。	它会加入一个公开列表，收集投票，并可能获得一个状态。	与你的账号无关。不会有针对你的回复，也没有时间表。
客服问题	你的账号出了问题——访问、限制、付款、丢失了什么东西。	一条发往人工队列的消息，最终会得到私下答复。	它不会为所有人修复某个 Bug，而且对任何不针对你个人的事情都很慢。
自动限制申诉途径	发送消息、加入或给陌生人发消息受限这一特定情况。	一次自动交互，可以解除或解释该限制。	它只处理一个狭窄的问题，其他任何内容都不会在这里被阅读。
在群组里提问	弄清是你、你的手机，还是真的坏了。	遇到过同样问题的人五分钟内就能告诉你。	它触及不到任何能改变什么的人。这是诊断，不是报告。

先问这个问题是应用的问题还是你账号的问题。这一个问题几乎能把所有内容正确分流。

四件事，几乎别无其他：你做了什么、发生了什么、你原本期望什么，以及你在哪个平台和版本上。包含这些的报告别人可以尝试复现；而一份只说“某个东西坏了”的报告，无论多么属实，谁都无法据此采取行动。

最有价值的补充是让它再次发生的方法。“每次只要聊天里有多于一条置顶消息就会发生”比任何数量的描述都更有价值，因为修复任何东西的全部难点就在于复现它。如果你无法稳定复现，也要说出来——这是信息，而不是失败。

功能请求遵循同样的规则，只是形式不同。“把它做得像另一个应用”是一种偏好，不会有结果。“我无法做这件具体的事，而我是这样替代的”描述了一个别人可以解决的问题，可能还是你没想到的方式，这正是提问而非指定的意义所在。

写之前先检查版本 相当一部分报告说的是某个已经在某个版本中修复、只是报告者还没收到的问题。更新一下，并说明你在哪个版本上，花一分钟就能完全省掉这番交涉。

多半是沉默，而这是正常结果，并非被忽视的迹象。公开的请求列表是温度计，而不是工单系统：它汇总显示人们想要什么，而你所贡献的有用东西就是一个数据点。

这也提示了合适的投入程度。搜索、投票，如果你的情况不同就补充具体情形——这十分钟花得值。写一大段论证你的请求为何重要，或者在毫无动静时换个说法重新提交，是把精力花在一个并不阅读论证的表面上。

任何关于你账号的紧急事项都不是这里 失去访问权、被限制、付款出错、有人冒充你——把这些发在这里只会拖延它们。它们属于客服途径，而处理它们的人不会去读功能列表。