If you’re the one raising objections to a solution:

• Before you object, weigh whether or not your objection reveals a serious issue. It’s okay to make a remark like “I believe there is a better decision and it’s this, but I’m also okay with the current choice.” It’s also okay to suggest improvements to the idea (or the implementation, if you’re discussing a pull request for example) without vetoing the current choice. Make clear what type of objection you’re raising.
• If you believe the choice has a blocking flaw, try to make your feedback as clear as possible so that the decision-maker can address it properly.
• If you believe the choice has a blocking flaw, try to find enough time and energy to convince opponents. When you differentiate between non-critical feedback and a fundamental flaw and prioritize the latter, you’re able to conserve the time and mental energy for the most important discussions.

If you’re the one deciding:

• Be vigilant and make sure the discussion doesn’t stall on non-critical, “not the best solution” feedback.
• If there is a discussion which cannot converge, ask participants to clarify if objections to a proposal address fundamental flaws or remarks which should be taken in consideration.
• If there is a good enough solution X, don’t ask people what they think about it. Instead, ask everyone if they can live with it and if not, why.
• Don’t feel like you have to default to majority rule.

Consensus is the path, not the destination

A final quote from the IETF document:

We don’t try to reach consensus in the IETF as an end in itself. We use consensus-building as a tool to get to the best technical (and sometimes procedural) outcome when we make decisions.