Voting

Core Concept

Voting lets team members express preferences, but Arbtr is not a democracy—the decision owner makes the final call.

Voting Philosophy

Arbtr supports voting, but with an important caveat: votes are informational, not binding. The decision owner sees what the team prefers, but makes the final call based on all factors—including strategic context that may not be visible to everyone.

This approach reflects how architectural decisions actually work in practice. A junior developer's vote counts, but the Staff Engineer who understands the full system context makes the call.

Arbtr's core value proposition is Relationships over Voting. The decision graph (dependencies, conflicts) matters more than vote counts. Voting is a tool, not the goal.

How Voting Works

Cast your vote: Click the vote button on any position to indicate your preference.
One vote per decision: You can only vote for one position per decision. Voting for a new position removes your previous vote.
Change your mind: You can change your vote at any time before the decision is concluded.
See results: Vote counts are visible to all team members (unless anonymous voting is enabled).

Voting Modes

Open Voting (Default)

Everyone can see who voted for what. This encourages accountability and allows for follow-up discussions about why people voted as they did.

Anonymous Voting

Vote counts are visible, but not who voted for what. Use this for sensitive decisions where team dynamics might influence votes. Enable per-decision in the decision settings.

Vote Deadlines

Decision owners can set a voting deadline to encourage timely participation:

Deadlines appear in the Pulse dashboard inbox
Team members receive reminders as the deadline approaches
After the deadline, voting is closed but the decision remains open
The owner can extend or remove deadlines at any time

tip

Setting a deadline creates urgency without forcing a premature decision. The owner can still wait for more discussion even after voting closes.

Owner Override

The decision owner can conclude a decision with any position, regardless of vote counts. This is by design:

Strategic context: The owner may have information others don't (budget constraints, roadmap plans, executive direction).
Technical authority: Sometimes the most popular option isn't the best technical choice.
Accountability: The owner is responsible for the outcome, so they get the final say.

When the owner selects a position that wasn't the most popular, they should document their reasoning in the decision rationale.

When to Use Voting

Good for Voting

• Decisions with broad team impact
• Multiple viable options with trade-offs
• Gauging team sentiment before deciding
• Building buy-in for a direction

Less Suited for Voting

• Highly technical decisions requiring expertise
• Decisions constrained by external factors
• When the right answer is clear but unpopular
• Security or compliance decisions

Voting Permissions

Voting requires the participate permission level for the voting category.

By default:

Owners: Can vote (manage level)
Admins: Can vote (participate level)
Members: Can vote (participate level)

Team admins can adjust voting permissions per-member if needed.

Arguments

Importance

Command Palette