Lab 03 — Consensus Tracker
What You'll Build
A model of the Apache lazy-consensus process for design proposals on the
dev@ mailing list — tracking +1/0/−1 votes from PMC members, detecting
blocking objections, and evaluating whether lazy consensus has been achieved
after the 72-hour minimum window.
Apache Consensus Rules
A design proposal achieves lazy consensus when:
- The 72-hour minimum discussion window has elapsed.
- No binding (PMC member) −1 objection remains unresolved.
- At least one binding +1 was cast (to confirm the proposal was noticed).
A proposal is blocked when an unresolved binding −1 exists — regardless of how many +1 votes were cast.
An objection becomes resolved when the proposer addresses the stated concern and the objector withdraws or explicitly acknowledges the resolution.
Running
mvn test
Expected: 10 tests, 0 failures.
Key Classes
| Class | Role |
|---|---|
ConsensusVote | Enum: PLUS1, ZERO, MINUS1 |
PMCVoteEntry | voter + vote + binding flag + comment + resolve() |
ConsensusResult | Enum: LAZY_CONSENSUS, BLOCKED, PENDING |
ConsensusProposal | title + proposedAt + vote list + objection helpers |
ConsensusEvaluator | evaluate(proposal, nowMillis) → ConsensusResult |
State Transitions
PENDING
├── blocking objection raised → BLOCKED
├── objection resolved + window elapsed + binding +1 → LAZY_CONSENSUS
└── window elapsed + binding +1 (no objection) → LAZY_CONSENSUS
Interview Angle
Distinguish lazy consensus from a formal [VOTE] thread. Lazy consensus is
appropriate for design proposals and code changes. A formal vote is required
for releases, new committers, and PMC membership changes. Interviewers at
staff/principal level will ask you how you would build consensus across a
distributed team for a controversial design change — describe sending
[DISCUSS], giving ≥ 72 hours, addressing each technical objection in writing,
and calling a formal vote only if lazy consensus fails.