这个问题有用而明确->我同意
这个问题不清楚或没有用->我不同意
此答案有用->我同意
此答案无用->我不同意
...遵循这些原则。
#1 楼
刚刚在meta上拒绝了功能请求后，我看到了工具提示，并认为完全一样。我会建议基于适用于该问题的“特殊”标签（例如功能请求），建议元站点上的工具提示的内容应根据上下文而定。我怀疑它是否会被视为UI中的高优先级工作，但是如果功能请求后投票的工具提示读为类似“请考虑解释为什么不同意的原因”，那会有点“整洁”此功能请求”。用户界面需要的“最后1％润饰”之一。
评论
就我个人而言，我认为这很重要，因为我发现这很令人困惑，并且我认为对于Meta上的“否决”表示什么，我并不孤单。
–凯尔·斯特兰德（Kyle Strand）
13年4月26日在19:53
@KyleStrand，我的：meta.stackexchange.com/questions/231023/…
– Paul Draper
2014年5月5日下午6:29
@Rob：使它更具上下文。到底是在问什么。
–user2284570
2015年12月29日在21:37
我认为将其与上下文相关是非常重要的-我没有意识到支持/拒绝投票对于功能请求的工作方式有所不同，我依靠工具提示来向我进行解释。
–kylejrp
20年12月19日下午2:00
#2 楼
我同意这项提议，并认为应按照OP的提议更改工具提示。但是Chris的评论很好，我认为需要解决：仅仅因为它在meta上并不能阻止问题不清楚和没有用-因此工具提示不需要扩展
在meta上肯定有一些简单的支持问题—为什么当我的投票数达到200时，我的投票为什么不再给我代表？主持人为什么删除我的答案；但是，我认为大多数Meta问题或至少占用最多时间的Meta问题都是讨论和功能请求。这些问题使新的工具提示有意义，并且我认为系统应该设计为尽可能地简化这些问题。
将工具提示扩展到适用于所有内容将很笨拙：我同意，除非这是一个支持性问题，在这种情况下，此问题是有用且明确的。因此，为什么不更改工具提示，以使它们在大多数时候，最重要时才适用，而不是现在，在工具提示仅最不重要时才适用。
评论
哦，你偷偷摸摸...
–casperOne
2012-03-14 19:48
@casper-我的意思是回答的每一句话，但是想到获得500pt赏金...哇...让我们说Peter Luger很难击败它。
–亚当·拉基斯（Adam Rackis）
2012年3月14日19:49
现在，我恨你=）
–casperOne
2012年3月19日在21:01
嘘！ :-D _____ @cas
–亚当·拉基斯（Adam Rackis）
2012年3月19日在21:04
#3 楼
提出要求后的3.5年，仍然存在同样的争论。可以说使用模式比正确的工具提示命名更为重要。但是，有一个观察结果：人们也反对功能请求，如果他们不同意，不管工具提示说什么。
我们可能会改变。更改将是仅对功能请求的答案进行同意/不同意投票。我们要么这样做，要么专门更改工具提示，以使有关元标记功能请求的问题答案的工具提示如下：
“此答案很有用，我同意”和“这个答案要么没有用，要么我不同意。”
这只能描述过去几年的实践。人们大多对功能请求的答案投票表示同意/不同意。但这将有更多机会减少对纯粹表达异议的功能请求问题的反对。
PS：实际上，功能请求应表述为中立的（“什么是最好的方法？” ），第一个答案应该是提问者的建议。
评论
您的答案主要假设或提出了不同的功能请求方法-这不是此答案的主题。如果您希望做到这一点，则应该在一个恰当的问题中提出建议（或者按照您的方法，在对新问题的自我回答中提出）–尽管我怀疑您会为该提议找到很多支持。
– Wrzlprmft
14-10-21在11:18
@Wrzlprmft感谢您的评论。我认为这不是一个不同的功能请求，而是部分满足，仅适用于特定情况。妥协。我认为它仍然与功能请求足够相似。一个“是，但是”可以这么说。
– Trilarion
14-10-21在11:31
#4 楼
我不同意此请求。虽然“我同意”和“我不同意”是可以在元数据上使用投票的一种方法，但这不是唯一的方法，我也不会希望将这种信息灌输给用户，作为对meta进行投票的“正式”含义。
当前的工具提示正确无误，现在每个meta的帮助中心都涵盖了更多细微之处：
https://meta.stackexchange.com/help/whats-meta
评论
我不同意这个有用的答案。我该怎么办？下注？正交投票？跳下桥？ ;-)
–卢卡斯·埃德（Lukas Eder）
2012年5月31日下午14:59
鉴于同意/不同意行为在meta上得到广泛使用和广泛接受，我相信meta站点上的工具提示应包括这种用法-如果只是为了阻止每位获得反对意见的新meta用户停止相同的模式，请问这有什么问题他们的问题被提及为“在meta上的投票不同”的众多讨论之一，然后想知道为什么它没有在按钮上这么说！
–疯狂
2012年6月18日13:39
我不知道为什么这么低估，因为我认为这是正确的。 “同意/不同意”投票仅应用于提案或建议。其他帖子，例如询问“为什么关闭此问题”或“这是一个错误”的问题，应该以与评估其他任何SE问题相同的方式进行评估。写得好吗？它显示出研究成果吗？它有用吗？
–雷切尔（Rachel）
2012年11月29日17:02
我们没有理由无法避免对任何问题进行同意/反对投票！只需对答案投票同意！对于提案来说，所要做的只是一个简单的“是的，应该接受该提案”，供人们投票。如果更改了工具提示，则将很难转换到更好的模型。
–上午
13年6月17日在18:02
我试过了，活着被烧死了。有人告诉我“请不要进行民意调查”，但我不了解这就是对meta进行投票的方式。问题是投反对票也是一种匿名的方式来表达您的问题很多。 “它被否决了，因为它不在主题之列。” -来自Meta主持人的报价。 （不一定是他们的否决票，但谁知道呢？）
–马祖拉
2014年8月9日下午0:47
您的回答以“我不同意此要求”开头似乎有点讽刺。
–zondo
16年11月6日在19:55
评论
投票可以（并且应该）也具有相同的含义-只是因为它位于meta上并不能阻止问题不明确和无用的问题-因此工具提示不仅需要替换，还需要扩展。并非所有元问题都是自以为是的项目。有时，人们只想知道发生了什么。
这不是功能请求而是讨论吗？
@razlebe：IMO，一个功能请求正在请求功能更改或新功能。
确实。而你做到了，不是吗？ “您可以更改工具提示...”
@razlebe：功能是指行为。更改文本不会更改行为。
很公平。但是，感觉好像那里缺少标签。建议进行细微（但有价值）的更改应该是有效的。
如果需要开发人员来做，那就是功能要求。我已经相应地编辑了帖子。
@Dori：该标签没有说明要求开发人员执行此操作。实际上，这更符合我的观点...功能上的变化。
我指的不是标签Wiki所说的，而是指SE的工作流程。如何使事情发生：①让SE知道社区想要改变某些事情。 ②SE决定是否值得做，如果是，则优先级高。 ③它最终显示在某人的待办事项顶部。结果：任务完成。但是，除非步骤1完成，否则步骤2将一无所获。
杰夫为什么不明白这一点？因为这真的会在很多方面有所帮助吗？
Errr ...有工具提示吗？
@ChrisF，“元数据上的投票不同...在标记了功能请求的帖子上，投票表明同意还是不同意”（强调原文）meta.stackexchange.com/help/whats-meta
@Grace是否有机会重新考虑？
在SO和Meta上，IMO仍然需要在“我同意这一想法”与“对此问题进行了研究并明确”之间进行明确区分。我仍然认为人们在投票赞成他们的直觉级协议（并且仅仅因为他们不同意所做出的主张而错误地投票），这只是愚蠢的堆砌。这是一个很好的例子：meta.stackexchange.com/questions/248488/…。