由于在 Apache 框架内完成任务的基本方面之一是通过共识来完成，因此我们需要一种方法来判断我们是否已经达成共识。我们通过投票来做到这一点。
基本上有三种类型的投票
程序性
代码修改
软件包发布
对**程序性问题**的投票遵循多数规则的通用格式，除非另有说明。也就是说，如果赞成票多于反对票，则该问题被认为已通过——无论每类投票的数量如何。（如果投票数量似乎太小，不足以代表社区共识，则通常不会继续讨论该问题。但是，请参阅惰性共识的描述以了解修改因素。）
对**代码修改**的投票遵循不同的模型。在这种情况下，否决票构成否决权，投票组（通常是项目的 PMC）无法推翻。同样，当提出投票请求时，此模型可能会受到惰性共识声明的修改，但否决票的最终性质不会改变。在正常（非惰性共识）条件下，提案需要三张赞成票且没有否决票才能通过；如果未能获得所需的投票支持，则不会通过。然后，提案者要么撤回提案，要么修改代码并重新提交，或者提案只是作为一个悬而未决的问题搁置，直到有人将其删除。
关于某个**软件包**是否已准备好发布的投票使用另一种机制：是否有至少三张支持发布的约束性投票？有关投票和约束性投票要求的更多信息，请参阅发布策略。
谁可以投票在某种程度上是特定于社区的。
PMC 成员拥有正式的约束性投票权，但一般来说，社区鼓励所有成员投票，即使他们的投票仅具咨询性质。
在某些情况下和某些社区中，行使投票权会带来一些可能并非立即可见的责任。例如，在某些情况下，赞成票传达了“我批准**并且**我愿意提供帮助”的隐含信息。此外，反对票可能意味着“我反对，但我有一个替代方案，并将帮助实施该替代方案”。
社区应在其指南中详细说明投票的默示含义。但是，在**任何情况下**，如果某人的投票似乎不符合隐含的承诺，则不得将其视为无效：投票是意见的正式表达，而不是承诺的表达。
如果R-T-C策略生效，则赞成票会传达非常强烈的隐含信息，“我已亲自测试了此补丁，并发现它很好”。类似地，否决票通常意味着投票者测试了补丁并发现它不好，尽管否决权（在这种情况下是这种情况）可能基于其他技术理由。
如果您以前从未遇到过 Apache 中的投票流程，它可能看起来有点奇怪。投票以 -1 到 +1 之间的数字表示，其中“-1”表示“否”，而“+1”表示“是”。
中间值表示投票者感受的强烈程度。以下是一些分数投票的示例以及投票者使用它们可能传达的信息
+0：“我对此没有强烈的感觉，但我可以接受。”
-0：“我不会阻挠，但我宁愿我们不要这样做。”
-0.5：“我不喜欢这个主意，但我找不到任何合理的理由来证明我的感受。”
++1：“哇！我喜欢这个！让我们做吧！”
-0.9：“我真的不喜欢这个，但我如果其他人想继续进行，我不会阻挠。”
+0.9：“这是一个很棒的想法，我喜欢它，但我没有时间/必要的技能来提供帮助。”
PMC 成员在发布版本上的投票必须使用 +1、0、-1 才能被视为约束性投票。
投票期通常应持续至少 72 小时，以便所有相关人员都有机会参与，无论其地理位置如何。
对于代码修改投票，+1 票赞成该提案，但 -1 票是否决权，并使该提案失效，直到所有否决者撤回其 -1 票。
除非提案者声明投票使用惰性共识，否则代码修改提案需要三张+1 票才能通过。
我们建议对此类投票使用整数，因为投票者表达的意见是布尔值：“我批准/不批准此更改”。
关于某个软件包是否已准备好发布的投票使用多数批准——即至少三名 PMC 成员必须投票赞成发布，并且赞成票必须多于反对票。**发布版本不得被否决。**通常，如果有人发现严重问题，社区将取消发布投票，但在大多数情况下，最终决定权在于担任发布经理的个人。流程的细节可能因项目而异，但“至少三张+1 票的法定人数”规则是普遍适用的。
请注意，发布经理或 ASF 任何投票中的任何人均没有隐含的 +1。只有明确的投票才有效。鼓励发布经理对发布版本进行投票，就像任何审阅者一样。
合格投票者投出的 -1 票会使代码修改提案立即停止。这构成否决权，任何人都无法推翻或覆盖它。否决权将持续有效，直到且除非个人撤回其否决权。
为了防止否决权被滥用，投票者必须在否决权中提供技术依据，说明为什么更改不好（打开安全漏洞，对性能产生负面影响，等等）。没有理由的否决权无效且没有权重。
投票的替代方法是使用惰性共识的概念来衡量某事物的可接受性。
惰性共识只是“沉默即同意”的声明。当有人想通过这种方式确定社区的意见时，他们可能会使用这样的邮件消息
"The patch below fixes bug #8271847; if no-one objects within three
days, I'll assume lazy consensus and commit it."
当审查后提交策略生效时，您不能将惰性共识应用于代码更改。
人们倾向于避免冲突，并四处寻找替代方案——负责人、规则、流程、停滞。这些都不太可能是解决冲突的艰苦工作的良好替代方案。