Conversation
One page defining every term a voter or admin meets in the product: the five election states, all seven voting methods by their on-screen names, the four roles (owner, admin, auditor, credentialer) with what each can do, Basic vs Proportional Multi-Winner, Equal Support, Scoring Round / Automatic Runoff, exhausted ballots, quota, write-ins, the voter roll, test votes, preliminary vs official results, and the election-vs-poll vocabulary swap. Definitions are harvested from the product itself (en.yaml, the shared domain model, permissions.ts, the tabulators) rather than from voting theory generally, so each entry uses the exact on-screen name and is definite where the code is definite. Each entry leads with a one-line answer for a voter, then admin-relevant nuance. Cross-references use the .md link form and target only pages already on main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 48 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Deploy Preview for bettervoting ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Found by a consistency review across the whole help set. Each was checked against origin/main rather than reasoned about. - Finalized, and Email list: both said invitations are sent automatically -- one 'queues the voter invitations', the other 'when the election opens, BetterVoting emails each voter'. finalizeElectionController sets state and deletes test ballots; it sends nothing, and no scheduler exists. Invitations go out only when an admin sends them. This is the most consequential error in the set: believing it means an election opens and no voter is ever told. Two other pages already say this correctly, so the glossary was contradicting them. - Ballot ID: said the identifier is shown on the confirmation page. It is deliberately not. castVoteController scrubs it there, with the comment 'prevent voters from creating receipts (vote buying/coercion)'; it appears only via the receipt link. Documenting it as visible would have quietly undermined an intentional anti-coercion measure, so the entry now states where it appears and why it is absent from the browser. - Archived: said an admin can archive. archiveElectionController requires canEditElectionState, which is owner-only -- and the glossary's own Admin entry already said admins cannot change election state, so the page contradicted itself. - Also drops the 'for email-list elections' qualifier on receipts, which exist wherever an email address is known. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 participant
Description
Adds
docs/help/glossary.md— a single alphabetical glossary of every term a voter or an election administrator meets in BetterVoting or in an email it sent them.Coverage:
permissions.ts.Definitions were harvested from the product itself (
en.yaml, the shared domain model, the tabulators) rather than from election science generally, so each entry uses the exact on-screen wording and stays definite where the code is definite. Every entry leads with a one-line answer for a voter, then admin nuance.Mechanics: front matter parents to
BetterVoting Documentation(nav_order 17); internal links use the.mdform and target only pages already onmain. Verified with a localgithub-pagesJekyll build — the page renders, appears in the nav, and every relative link rewrites to.html.Screenshots / Videos (frontend only)
N/A — docs only.
Related Issues
None.
🤖 Generated with Claude Code