Community Based Decision Making, as it's evolved within the HTTP Server Project and applied to the Apache communities, refers to the process where the voice of the majority is generally followed, but the voice of the minority is heard and respected.
Almost all decisions within Apache projects are made by consensus. Of course there is no way that every decision to be made can find a consensus, but most decisions have one. The trick to this process is open discussion of not only code, but of the goals behind the code. Once all of the participants understand the individual needs behind a design decision, the code to satisfy the varied objectives becomes apparent, and consensus generally follows.
LazyConsensus is common within smaller projects or subcommunities of larger projects, where the absense of any strong objections leads to the proposed changes being adopted. This isn't the strongest case (it implies that the proposals aren't being reviewed or vetted closely) but is necessary because some tangents of the code don't have as many participants following that niche's development. As an example, some platforms have few coders vetting the patches that apply to that specific platform.
Active Consensus is the course of most code, where voting and affirmation of proposed patches validates that they are going in the right direction. Votes of +1 indicate agreement with the proposal, while votes of +0 or -0 indicate that the observer abstains from the vote, but is leaning in one direction or the other. With no -1's and a proponderance of +1 votes, code is accepted by consensus, and improved through the process of the discussion. Many committed patches are radically better than their original proposals, because of the detailed feedback that accompanies many votes.
Vetos ensure that no decision is forced upon the minority. In most technical discussions, a -1 vote reflects a veto of the proposed design or code. In all projects, the -1 vote must be accompanied by a technical justification for the negative decision. This justification should include alternatives that would satisfy the minority who raised the veto.
Vetos reflect one of several situtations. Either the project contributors are failing to listen to one anothers' requirements, or there is simply a better way of accomplishing the same thing. When contributors pay special attention to the voices of the minority, the end result is usually more flexible and closer to the project's overall direction.